Topic: A/V in BASS_StreamCreateFile

[rok]

My project has been plagued with a problem ever since its beginning over a year ago.  Basically, the program locks up at what appears to be completely random points.  The program is a dual MP3 player that simply plays MP3s from a playlist, fading one into the other. No big deal, right?

Well, here's the situation.  I've stripped everything down to the barebones (no visuals) with extensive trace logging to isolate the problem.  I'm using the same playlist (~500 songs) each time.  Sometimes the program will make it through 50-60 songs before it bombs, and sometimes it takes only a few.  There's no pattern.  If running under the IDE, I usually get an A/V that does not appear to be comming from the main thread.  If running outside of Delphi, the program just stops and the sounds sticks until I kill the task.

The last error that I got was:
A/V at 0x1000bc42 read of 0x0000111c

Logs showed:
12:26:52:359   ==========================
12:26:52:359   Loading C:\My Music\SHAG CDs\Shag CD # 02\#02 - 02 - Coastline - New Old Songs.mp3
12:26:52:875   Stream created 1610612926
12:26:52:875   Reading Tag
12:26:52:875   Tag Read
12:26:52:875   Setting Syncs
12:26:52:875   Syncs Set
12:26:52:890   Analyzer Start
12:26:53:062   Got Info
12:26:55:578   Analyzer Stop
12:26:55:593   Track Cued
12:26:55:593   Setting Syncs
12:26:55:593   Syncs Set
12:27:01:859    - Fade -
12:27:02:468    - Mix -
12:27:07:343    - End -
12:27:11:859    - Load -
12:27:11:859   ==========================
12:27:11:859   Loading C:\My Music\SHAG CDs\Shag CD # 02\#02 - 03 - Clovers - Drive It Home.mp3


The code executed in main thread:

Code: [Select]


 Trace('==========================');
 Trace('Loading '+AFile);
 H := BASS_StreamCreateFile(FALSE, PChar(AFile), 0, 0,
                                 BASS_MP3_SETPOS);
 Trace('Stream created '+IntToStr(H));
 BASS_StreamPreBuf(H);
 FVolume := 100;
 FLength := BASS_StreamGetLength(H);


From the appearance of the logs, it looks to me like the BASS_StreamCreateFile() faulted.  But this is just one case,  I'm sure that if I run it again, it will fail in some other place.  

Well, actually it just failed while I was typing this. This time, the A/V is at 0x1000aa2b write of 0x0000000c.  The log seems to show the problem occurred on the same call, but on a different song in the list - (6 songs earlier this time).

Any light that you can shed on this would be very much appreciated, as this has hampered what would otherwise would be a very exciting project.  Thanks.

--------
Delphi 5 - BASS 1.8a - Win 2000 - SB Live
My Dell has dual processors, but the problem occurs on other machines, too.

[rok]

I've posted the source to my stripped down test project (10k) on my web site, for any of you that are interested.

Here's the link:

http://jcent.com/RoksBASSTest.zip  (case-sensitive)

[Ian @ un4seen]

Does the problem only happen when using the BASS_MP3_SETPOS flag? I can't be certain from just the crash locations, but I suspect it's during the scanning of the new MP3 stream. Anyway, I'll send an update to try.

[rok]

I have always used the BASS_MP3_SETPOS flag, so I don't know if it is the culprit.  I can try it, but I think that my project will require the increased accuracy once this problem is solved.

Btw, thanks for your quick response.  My inability to resolve this problem has thrown the brakes on any further development. Every few months, I'll pick the project up again thinking that a fresh attitude (or newer BASS version) will do the trick.  So far, this is the only wall that I keep hitting.

Please let me know if there is anything that I can do to help.  I understand how difficult it is to track down errors that are hard to reproduce consistently.  [My last run of the test project took 46 songs before it failed.]

[suathd]

Similar problem occurs whenever, "Result:=True" line is forgotten in callback functions (SYNC_PROC) .

[rok]

Similar problem occurs whenever, "Result:=True" line is forgotten in callback functions (SYNC_PROC) .

I use the BASS_SYNC_MESSAGE flag when setting syncs.  It was not my first choice, but after this problem kept creeping up, I decided to simplify things and let the main thread handle the sync messsages.  I may go back after my confidence is restored.  But thanks for the tip!

Ian!  
I removed the BASS_MP3_SETPOS flag from both the playing channel and the decoding channel that I use to detect the leading/trailing silence and average amplitude (used later to normalize the volume).  Guess what?  No errors yet, with 75 songs and counting!!  [fingers-crossed] My mixes sound a little better too.    Maybe I don't really need that thing anyway.

[rok]

That had to be it!  130+ songs and no more A/V!!  And, all I did was remove the BASS_MP3_SETPOS flags.  Something's amiss with that thing. I only wish I had tried it 10 months ago!!  

Thanks for your help, Ian.  I think this is a great library!!

[rok]

 2575 songs and still playing without a hickup.

So Ian, could you tell me what I'm giving up if I don't use the BASS_MP3_SETPOS flag?  How close is the approximation?  Before playing, I use BASS_ChannelSetPosition() and BASS_ChannelGetData() on a decoding channel to detect lead/trail silence and set my cues and syncs accordingly.  

What functions are affected by the BASS_MP3_SETPOS flag?  What about BASS_ChannelGetPosition()?

[biggyspender]

I'm worried... I've been writing a custom streamproc to implement sample accurate timing/mixing... MP3_SETPOS is a vital element of the whole process.
I have to say, I've never had any problems, but it's all very preliminary, and I've not had any need to open more that 2 or 3 streams per execution. I'll be watching this thread with interest.

[Ian @ un4seen]

So Ian, could you tell me what I'm giving up if I don't use the BASS_MP3_SETPOS flag?  How close is the approximation?  Before playing, I use BASS_ChannelSetPosition() and BASS_ChannelGetData() on a decoding channel to detect lead/trail silence and set my cues and syncs accordingly.  

What functions are affected by the BASS_MP3_SETPOS flag?  What about BASS_ChannelGetPosition()?

BASS_MP3_SETPOS affects the length detection and seeking in MP3 streams, so the affected functions are BASS_StreamGetLength and BASS_ChannelSetPosition. BASS_ChannelGetPosition is unaffected.

When not using BASS_MP3_SETPOS, the approximation is generally very accurate (within a fraction of a second). The obvious exception is if the file is a VBR MP3 without a VBR header.

If you're looking to accurately detect trailing silence, you should use the BASS_MP3_SETPOS flag on the decoding channel (not so important on the playback channel).

Did the update I sent not fix the problem then?

[rok]

Ian,

I'm running the test again, as I write this, using the new dll and the BASS_MP3_SETPOS flag.  So far, it's up to 50 songs without problems.  I'll let you know in about an hour.

[Olego]

Uh-oh.  It's been more than an hour.  The new BASS probably crashed his hard drive!  ~Olego~

[rok]

Well, it looks like the new dll solved the problem.  It played over 2000 MP3s using the BASS_MP3_SETPOS flag, without any problems.

Sorry, that I didn't get back to you right away.  Thanks for your help and fast response, Ian.

[biggyspender]

Ian,

Do these fixes propogate into the released package?
I saw something last night that -might- be related... too soon to tell.

/chris

[Ian @ un4seen]

Yes. There'll probably be a 1.8b release shortly, with more little fixes/tweaks like this, before I then concentrate on 2.0. If you like, I can send the latest DLL, to see if you can recreate "last night" with it

[biggyspender]

I'll survive until then... stuck in the depths of fourier hell at the moment...