PDA

View Full Version : HLS crashess when trying to play audio with preview



Petulka77
11-28-2013, 12:33 AM
HLS keeps crashing in my sequence every time I have preview open and select Play from Mark or Play/Pause.
Here is a link to my PCM and hls files (https://app.box.com/s/eqegpbrbadan9o97sltr) for debugging.
It seems to be related to my sequence only.
FYI: This sequence is based on image and is also based on a wav file which gave me warning about corrupted audio. But it plays without issue if Display Preview is unchecked.
The audio issue is related to this thread :http://doityourselfchristmas.com/forums/showthread.php?29714-Error-after-picking-WAV-file-when-starting-sequence
(http://doityourselfchristmas.com/forums/showthread.php?29714-Error-after-picking-WAV-file-when-starting-sequence)

JHinkle
11-28-2013, 12:49 AM
In a different post on this topic - you stated HLS reported bad audio. If the Error said the Audio was bad - why continue?

Your error of play from Mark - is audio -- hence most likely a domino effect from the first error message.

The WAV file was unacceptable - you should not go any further until THAT issue is addressed.

In a previous post - I stated it looked as if your WAV parameters were not acceptable.

HLS does more than just play the audio -- it is synced to the audio --- THAT is why I need audio correct before any sequencing is started.

Please address the audio issue first reported and all should be well.


Joe

Petulka77
11-28-2013, 12:55 AM
OK. Fair enough.
The reason why I continued is because I did not know what else I should do about the audio to make HLS happy.

Would you be able to tell me what is wrong with the audio to be able to fix it?

JHinkle
11-28-2013, 01:16 AM
It is crashing up in Windows.

The call stack is buried in window calls - I can't even see which of my threads are involved.

Can you send me the WAV file so I can load it from start myself?

If you loaded channels from a Library --- please include it and tell me what Layout you loaded.

Thanks.

Joe

Petulka77
11-28-2013, 01:49 AM
Well, it looks like it's not even related to the audio since I found a way to make HLS happy about the file using mp3 after couple variation attempts (no error warning in audio section anymore).

Then I started the sequence again based on this mp3 and the image what I had. Now I run to the same issue again (It crashes every time when playing with preview).
I have packed the whole new standalone sequence (https://app.box.com/s/5gqqy1f28wb4ovl3s1o5) including:
- the mp3 file (HLS is happy with),
- library folder with my only image (MusicBoxDancer_Image_114593.img).
- and other sequence related files

Now you have the whole sequence to look into.

I have also noticed of one weird thing. (Maybe not related to the issue).
When I started the new sequence based on the image the hls file size on the parent sequence was around 800MB.
I expected that the new sequence hls file will shrink down and will be smaller. But it actually grew up to 1.2 GB with almost no effect in it.

Thank you Joe for your help. It's a show stopper for me now.

JHinkle
11-28-2013, 11:02 AM
I only got 3 hours of sleep last night --- could not stop thinking about this.

Up at 4:30AM to tackle it again.

I finally understand and will share what I found.

YOU BROKE IT!!!!!!!!!

When I saw the size of your song --- I knew THAT was the key -- but where.

When you ask to play the song, I allocate memory from the heap to hold the audio to be worked. I was using classic C++ new.

It was the new that was failing. I stepped deep inside Microsoft's code --- and finally came to the HeapAlloc call which was returning zero --- which means no memory was allocated.

Microsoft has an issue because new is expected to return the zero pointer stating that no mem allocated. Instead - MS's current new implementation crashes.

I fixed MY code by directly calling HeapAlloc --- thereby sidestepping the C++ new and MS issue.

So --- the crash is now resolved --- but WHY are we not allocating memory??????

Win32 allocates 4 gig of virtual space to every process. Windows takes half and the program gets the other half.

So ... each program using 32bit Windows has 2 gig of virtual memory for heap, stack, DLLs, etc.

YOU BROKE THE 2 gig limit --- THAT is how you broke it!!!!!

Win64 gets 4 gig of virtual memory --- I really don't want to produce both a 32 and 64 bit version --- time will tell.

Your Song is more that TWICE the length of a "normal" song --- it's 5 minutes.

Take the length of your song and the number of Channels you use (10,741) --- and you are at the limit of virtual memory.

I added a report to let people know what the stats on their sequence is. I could not find a GOOD place for it --- so I placed it in DEFAULT.

This is the report on your sequence.

21566

The length of your song requires 5947 Timing tics that can hold effect data.

Combine that with 10,741 channels and your CHANNELS alone require 1,714,532,892 bytes of virtual memory .... HLS has more memory requirements besides THIS --- but this is the BIG GUY!

Compare your sequence to another users sequence --- slightly smaller channel count but the song is about half the size.

21567

This user has a LOT of memory left.

So moral of the story ... as your Channel Count goes UP .... you have to keep the length of you song down --- NOT 5 minutes.

The name of the audio suggests it just background music --- make several SMALLER sequences instead of one LARGE one.

By the way ... if you use the new BACKGROUND capability --- memory goes up even MORE.

S0 --- use a smaller song and all will be well.

I'm sorry I can't fix this. I never thought I would see it --- but you hit the wall.

I hope this explanation helps.

Joe

jlowe
11-28-2013, 11:12 AM
Wow. Very thorough explanation. Without question, with the complexity that displays are starting to have, I can see this occurring more frequently. Sorry you didn't get much sleep, but I bet it was a great "aha!" moment when you figured out the culprit!

cnbales
11-28-2013, 11:19 AM
This hobby has taught me something great... The frustrating aspects have become less frustrating because the "Ah-Ha" moments are incredibly rewarding. This has spurred me on to pursue other areas of information technology.

Petulka77
11-28-2013, 11:26 AM
Joe, thank you very much for the explanation. All make sense now. I am sorry you did not get enough sleep because of my sequencing.
I'll cut the song in half. That's not a problem for me at all.
At least you discovered correlation between the channels, song length and hardware limits. That way users have to keep the layout & song length in mind before sequencing.
64-Bit version is not necessary at all. Simply says: We can't just abuse HLS if we don't have to. That's all.
Please take a nap and enjoy your turkey. Happy Thanksgiving.

angus40
11-28-2013, 11:45 AM
Joe, thank you very much for the explanation. All make sense now. I am sorry you did not get enough sleep because of my sequencing.
I'll cut the song in half. That's not a problem for me at all.
At least you discovered correlation between the channels, song length and hardware limits. That way users have to keep the layout & song length in mind before sequencing.
64-Bit version is not necessary at all. Simply says: We can't just abuse HLS if we don't have to. That's all.
Please take a nap and enjoy your turkey. Happy Thanksgiving.


Huh ? 64 bit should be standard issue . by default 32 bit windows caps the max mem at 4 gig

Petulka77
11-29-2013, 12:12 AM
Huh ? 64 bit should be standard issue . by default 32 bit windows caps the max mem at 4 gig

I should probably say: 64-Bit version is not necessary for right now.

deonb
11-29-2013, 07:07 AM
Microsoft has an issue because new is expected to return the zero pointer stating that no mem allocated. Instead - MS's current new implementation crashes.

Not quite. (Unless you have a VERY old version of Visual C++).


Microsoft now follows the C++ standard, which is if 'new' fails to allocate memory it will throw a std::bad_alloc exception. (N3291, 5.3.4.13 - "Note: unless an allocation function is declared with a non-throwing exception-specification (15.4), it indicates failure to allocate storage by throwing a std::bad_alloc exception (Clause 15, 18.6.2.1); it returns a non-null pointer otherwise.")

Best is to just catch the std::bad_alloc exception and handle it gracefully, so it doesn't appear like a crash to the user.


However, if you really want to have new return null on failure, you can pass std::nothrow to new.


e.g.

#include <new>
#include <stdio.h>

int main()
{
try
{
void* p = new char[0x7fffffff];
}
catch (std::bad_alloc&)
{
printf("Caught a bad_alloc\n");
}


void* p = new(std::nothrow) char[0x7fffffff];
printf("Value of p: %p\n", p);
}


Prints:

Caught a bad_alloc
Value of p: 00000000



Alternatively you can globally overload operator new & operator delete to always return null on failure, but I wouldn't recommend it. It will break interop with various libraries, including the STL, and just make things difficult for you down the line.



[EDIT] Groan. Don't think the forum software has a good way to format & indent code. Tried both tabs & spaces.

deonb
11-29-2013, 07:22 AM
I'm sorry I can't fix this.

Easiest way to fix this is to link HLS with /LARGEADDRESSAWARE, which will give him an extra 1 gb (32-bit O/S) or 2 gb (64-bit O/S) for his sequence.

Maybe don't enable it mainline at this stage, and just do a private drop for him with /LARGEADDRESSAWARE enabled until you're sure HLS can run fine with that.

To enable that, in the Visual C++ linker settings for your project, under "System", change "Enable Large Addresses" to "Yes". This doesn't make it a 64-bit process (which is a much more intensive engineering effort), it just change the usermode/kernelmode address boundaries to give a bit more space to user mode.


Then, Petulka77, to be able to use that you need to either run on 64-bit Windows, or run on 32-bit Windows but boot with /3GB.
http://msdn.microsoft.com/en-us/library/windows/hardware/ff556232(v=vs.85).aspx

JHinkle
11-29-2013, 10:06 AM
deonb:

Thanks for the post.

I use VS2010 Pro.

I rarely use try/catch and never with new (didn't know that is how MS did it now. My c++ learning was reading Bjarne Stroustrup's book about 15 times back in 1995. I don't think it was the standard back then). I'm really an "old" assembler an C guy in the embedded world.

I will modify all of my new statements to include the nothrow.

I will also change the acquisition line for the audio buffer from HeapAlloc back to new (for any that are interested) now that new will return a null pointer.

Thanks you also for the linker flag for the extra 1 or 2 gig of space.

I searched the net and msdn for hours yesterday looking for the 32bit limit and never came across this compiler flag as a way to extend it.

Next release will extend memory for all --- thanks again.

Joe

gassy
01-27-2014, 11:15 AM
Don't know if this is still an issue, but I was having the same problem (19N) of crashes when trying to run a preview. I realized the problem started about the same time that I installed a new anti-virus program and once I turned off the 'Live Protection' service I no longer had a problem running the preview. FWIW.