Author Topic: BASS 2.4.12 / BASS_StreamPutFileData / BASS_ERROR_ENDED / push stream / MP3 data  (Read 822 times)


  • Posts: 10
Dear Sirs,
   I'd like to submit a suspect behaviour of method BASS_StreamPutFileData with "push" streams (I've attached a file with log file produced by same code and same data but different version of BASS (2.4.9, 2.4.11)).
In attached file you'll find the VB.Net, Framework 2.0, x86, (Visual Sudio 2013) project written to simulate different behaviour of BASS_StreamPutFileData.

Using BASS to decode single (or miltiple) MP3 frame to PCM data

With BASS 2.4.9 following approach is working well :
- a) let <MP3_AUDIO_BUFFER> be the buffer contaninng one (or more) MP3 audio frames
- b) let <PREBUFFER> be the result of concatenating almost 4000 bytes of data repeating <MP3_AUDIO_BUFFER>
E.G. : <MP3_AUDIO_BUFFER>(1)...<MP3_AUDIO_BUFFER>(n) until the "sum" of <MP3_AUDIO_BUFFER> length is greater than or equal to 4000
- c) via BASS_StreamCreateFileUser callbacks BASS "process" <PREBUFFER> returning a valid "push" stream handle
- d) call BASS_ChannelGetInfo to retrieve channel properties
- e) call N (N >= 1) times BASS_ChannelGetData to "consume" <PREBUFFER> data (Last call, obviously, fail returning 0 with 2.4.9 and -1 with 2.4.11 or newer)
- f) now the tricky part :
- f.1) push <MP3_AUDIO_BUFFER> in the stream via BASS_StreamPutFileData method
- f.2) retrieve decoded PCM data via BASS_ChannelGetData
- g) save PCM data for further processing
- h) repeat points from f) to g) until some event occur

ISSUE RELATED DATA (in attached file)
- please see file "BASSPushTest_with_BASS_2.4.9.log" to verify the behaviour of BASS 2.4.9
- please see file "BASSPushTest_with_BASS_2.4.11.log" to see the new behaviour of BASS 2.4.11

What is changed with BASS 2.4.11 / 2.4.12 (please see sub folders BASS_2.4.11 and BASS_2.4.12 in attached file) ?
- points from a) to e) still complete with "success"
- points f.1) and f.2) fails with reason BASS_ERROR_ENDED (45)

Is the latter the new (and possibily correct) behaviour of BASS ?
In either case is the above approach a "misuse" of BASS ? In this case could you suggest a valid one ?

Many thanks in advance,
« Last Edit: 21 May '16 - 15:50 by axel »

Ian @ un4seen

  • Administrator
  • Posts: 20499
I think these lines in the "BASSPushTest_with_BASS_2.4.11.log" file reveal the problem:

21/05/2016 14:59:20.742 > BassFileReadProc >> Return 0 byte (length=1443)
21/05/2016 14:59:20.742 > BassFileCloseProc >> Nothing to do

When a FILEREADPROC function returns 0 (and the STREAMFILE_BUFFER/PUSH system is used) that indicates to BASS that the file has ended, so it then closes the file (calls the FILECLOSEPROC) and no more data will be accepted via BASS_StreamPutFileData.

So the issue seems to be that BASS 2.4.11/12 is asking for more data than you have. How many frames of MP3 data do you have? I think BASS 2.4.11/12 will look for at least 6 frames to verify MP3 data, even if that goes beyond the BASS_CONFIG_VERIFY(_NET) setting (that setting only limits how far BASS will look for the 1st frame).

Here's an update for you to try, which won't close the file when a FILEREADPROC function returns 0 and the STREAMFILE_BUFFERPUSH system is used:

Let me know if you still have any trouble with it.


  • Posts: 10
Hello Ian,
   thank you very much for your valuable support !

I'm testing attached version of BASS ( in this very moment observing the expected (previous) behaviour.

Now my answers to help you to figure out as much as possible the scenario:

- So the issue seems to be that BASS 2.4.11/12 is asking for more data than you have
> initial condition : no data available, BASS still not involved (no MP3 data to decode)
> data available (first occurrence) : one or more MP3 frame extracted from RTP frame, I need to "feed" BASS (via BASS_StreamCreateFileUser) with at least 4000 bytes buffer of "replicated" MP3 frame/s
> after BASS_StreamCreateFileUser return a valid stream handle I ask BASS to decode (via BASS_StreamPutFileData + BASS_ChannelGetData) exactly the amount of MP3 data received (in worst case at least 1 (one) MP3 frame)
> more data available : I submit to BASS MP3 frame/s to get the corresponding PCM samples
> no more data available : I have to consider as invalid previous stream handle so the process restart from "initial condition"

- How many frames of MP3 data do you have ?
> In the attached test project 3 (three) putted together after extracting them from their respective RTP frame
> In worst conditions I'd like to "stream put" a single MP3 frame at a time to get the corresponding PCM data

Please feel free to correct my potential misuse of BASS ; )

Kindest regards,


  • Posts: 10
Hello Ian,
   everything seems to work properly now.
Could you confirm the new behaviour (i.e. "update which won't close the file when a FILEREADPROC function returns 0 and the STREAMFILE_BUFFERPUSH system is used") in next BASS release too ?

Many thanks in advance,
Kindest regards,

Ian @ un4seen

  • Administrator
  • Posts: 20499
Yes, I don't think that change will cause any problems for existing users, so it will be retained in the next BASS release. Good to hear that it's working well for you.