Problem with StreamProc callback

[hukka]

I'm not sure if I'm doing something wrong or if it's a bug in BASS, but my streamproc doesn't like OGG Vorbis. I have a decoding channel containing an OGG file and an output channel. I decode the decoding channel OGG into the output channel in the output channel's streamproc callback.
Here's the problematic part of the callback code: (Delphi 6)

Code Select Expand

function StreamProc(handle:HSTREAM; buffer:Pointer; length:DWORD; user:DWORD): DWORD; stdcall;
var
    buf: ^byte;
    b: QWORD;
    decoded: array of byte;
begin
    buf := buffer;
    SetLength(decoded, length);
    ZeroMemory(decoded, length);
    b := BASS_ChannelGetData(decode_channel, decoded, length);
    MainForm.AddToLog(false,'req:' + inttostr(length) + '  got:' + inttostr(b));
    (buffer stuff omitted)
    Result := length;

The problem is that ChannelGetData often fails. It doesn't report an error value, but instead it just completely freezes for a few seconds (even half a minute), then starts giving bogus values. Like this:

(Song started)
req:17640  got:17640
req:3738  got:3736
req:8004  got:4294967295
req:5898  got:4294967295
req:2924  got:4294967295
req:8846  got:4294967295
req:5870  got:4294967295
(etc, etc..)


MP3 and WAV files work fine with the same code. Some OGG files also play OK, but most of them fail.
Also, another weird thing is that if I request a consistant, small value from ChannelGetData, for example 4096, it doesn't fail/freeze. But obviously that isn't good enough as I need the exact length amount of bytes.
Can somebody help me?

[Ian @ un4seen]

The problem is that ChannelGetData often fails. It doesn't report an error value, but instead it just completely freezes for a few seconds (even half a minute), then starts giving bogus values. Like this:

(Song started)
req:17640  got:17640
req:3738  got:3736
req:8004  got:4294967295
req:5898  got:4294967295
req:2924  got:4294967295
req:8846  got:4294967295
req:5870  got:4294967295
(etc, etc..)

This looks like the file has reached the end... you requested 3738, but only got back 3736. Then it constantly returned 4294967295, which is also -1 (or DW_ERROR in the Delphi API). Check the error code (BASS_ErrorGetCode), it's probably BASS_ERROR_NOPLAY.

Btw, BASS_ChannelGetData actually returns a DWORD (not QWORD), but I don't think that'd cause a problem.

MP3 and WAV files work fine with the same code. Some OGG files also play OK, but most of them fail.
Also, another weird thing is that if I request a consistant, small value from ChannelGetData, for example 4096, it doesn't fail/freeze. But obviously that isn't good enough as I need the exact length amount of bytes.

That's strange. Do the files play properly in the precompiled BASS examples? Please upload 1 or 2 of the problem files, and I'll take a look.
      ftp://ftp.un4seen.com/incoming/

[hukka]

This looks like the file has reached the end... you requested 3738, but only got back 3736. Then it constantly returned 4294967295, which is also -1 (or DW_ERROR in the Delphi API). Check the error code (BASS_ErrorGetCode), it's probably BASS_ERROR_NOPLAY.

The file hasn't reached the end. I make sure to start them from the very beginning and the songs are generally about 4-7 minutes in length. And it fails in the first two seconds always, sometimes at the very first call to the callback routine.
Also, now it just freezes forever without even giving an error code. So it works for a few calls and then the program freezes completely and the hard drive starts swapping for a few seconds.

That's strange. Do the files play properly in the precompiled BASS examples? Please upload 1 or 2 of the problem files, and I'll take a look.
      ftp://ftp.un4seen.com/incoming/

The files are OK, but I just noticed that apparently the trend is that monophonic OGGs play OK, and stereo ones fail. I still don't know why that is. Yes, XMplay plays all of the OGGs fine, and so did BASS when I didn't use decoding channels. All other files but OGG play fine regardless of whether they're in mono or stereo. Any idea? There is enough space in the buffer for the decoded data, and it doesn't help if I change decoded into an array of SmallInt instead of array of Byte. I have no idea what to do.

[Ian @ un4seen]

The files are OK, but I just noticed that apparently the trend is that monophonic OGGs play OK, and stereo ones fail.

Ok. Looking at those numbers again, 3738 is not a valid number of bytes to request from a stereo 16-bit channel (3738/4 = 934.5). That's why it returned only 3736 bytes.

Is the custom stream stereo? (when the decoding channel is stereo) ... please post the code you're using to create it.

[hukka]

Ok. Looking at those numbers again, 3738 is not a valid number of bytes to request from a stereo 16-bit channel (3738/4 = 934.5). That's why it returned only 3736 bytes.

Is the custom stream stereo? (when the decoding channel is stereo) ... please post the code you're using to create it.

Okay, problem solved. I was setting some wrong flags in the initialization (my program didn't originally use decoding channels and I had accidentally left some BASS_MUSIC_* flags in my routine). Thanks for the help, I wouldn't probably have found the bug without it. BASS rules :o) (but please give us the ability to mute channels in modules in the future)

[Ian @ un4seen]

(but please give us the ability to mute channels in modules in the future)

See BASS_MusicSetChannelVol