Author Topic: problems with BASS_StreamCreatePush & stalling on Android  (Read 91 times)

pgruebele

  • Posts: 55
Semi-randomly my playback mixer triggers BASS_SYNC_STALL when using a BASS_StreamCreatePush stream even though the stream has data available.  I have played with lots of settings and am at a dead-end so hoping for a new direction in determining the cause of this.

Setup:

BASS_StreamCreatePush handle is added to a mixer with BASS_SYNC_STALL callback.  In order to avoid stalls, I configure everything and then wait until the stream has received 200ms of audio via BASS_StreamPutData before calling BASS_ChannelPlay(mixer).  I have verified that 200ms are indeed buffered AND that the stream is receiving input at a higher rate than playback.  When the stall  happens, it is typically immediately after BASS_ChannelPlay.  I can hear a very brief (fraction of a second) audio playback before my debugger stops in the stall callback.  In the stall callback I calculate the amount of buffered audio via "total_samples_pushed_into_stream - BASS_ChannelGetPosition" which shows e.g. total_samples_pushed_into_stream=10K & BASS_ChannelGetPosition=6K samples, so 4K ready samples left in the buffer (24Khz rate) available so the stream is definitely not stalled.

Strangely if I ignore the stall, things seem to work normally and I hear what appears to be glitch-free audio.  However, since a real stall could happen to the network stream, the callback runs a background task which pauses playback and waits for a further 200ms buffering before again calling BASS_ChannelPlay, which then frequently again stalls for no apparent reason.

Sometimes it just works.  Other times - especially if I just closed the stream and opened a new one - the stall callback is called right away.  If I stop in the debugger for a few seconds before calling BASS_ChannelPlay things appear to work more reliably.  Also, on one phone it happens hardly at all and on another quite frequently. Changing BASS_CONFIG_UPDATEPERIOD from the default 100 to 50 causes it to happen EVERY time even though I would expect this to improve things.  I have tried different BASS_CONFIG_DEV_BUFFER and BASS_CONFIG_BUFFER values but for now they are 700 and 500, respectively.

So there seems to be a corner case or timing/race condition. The fact that playback sounds normal when I ignore the stall callback seems to indicate that this is a false callback.  Also once playback starts successfully it can continue indefinitely without any stalls so this seems to be related to starting playback.

Any idea what could be happening or how I can debug this further?

Cheers
Philip


P.S.
I check for data==0 in the stall callback (it is a real stall) and BASS_ChannelIsActive(mixer) == BASS_ACTIVE_STALLED there as well.
Also I belive all my calculations using BASS_ChannelGetPosition etc are correct (I know it returns byte position).
I also use an intermediate tempo handle for tempo adjustment but removing this from the equation makes no difference.

Ian @ un4seen

  • Administrator
  • Posts: 21533
I suspect the issue there is that Android's audio buffer is actually larger than BASS's buffer (as set by BASS_CONFIG_DEV_BUFFER) on the affected device(s). That means Android may initially request more data than you are expecting, ie. it'll ask BASS to fill its allocated buffer and then immediately ask for more. To avoid an initial large spurt of buffering at the start of playback, you could try enabling non-stop output via the BASS_CONFIG_DEV_NONSTOP option, so that Android's buffer is already full (of silence) before the playback begins. If you haven't already done so, you could also see if using AudioTrack output (BASS_DEVICE_AUDIOTRACK flag) makes any difference.

BASS_CONFIG_DEV_BUFFER shouldn't be set higher than BASS_CONFIG_BUFFER because that means a stream's buffer can't hold enough data to fill the device buffer, which could result in a stall.

MB_SOFT

  • Posts: 267
I would add that i'm using BASS_StreamCreateFileUser STREAMFILE_BUFFERPUSH on Android and it works like a charm on all android devices that i tested. I receive a low bitrate mp3 stream form the network and i play it.

My configuration is:
BASS_CONFIG_AM_DISABLE,1
BASS_CONFIG_BUFFER, 200
BASS_CONFIG_UPDATEPERIOD, 40
BASS_CONFIG_VERIFY, 1000
BASS_CONFIG_VERIFY_NET, 1000
BASS_CONFIG_NET_BUFFER, 1000
BASS_CONFIG_NET_PREBUF, 20
all the rest is like bass default

after the stream creation i also set BASS_ATTRIB_NET_RESUME,20

the stream is mp3 mono 48 kbits 32000 hz so the settings could be changed a little according to file rate and format

keep it a try if you want

pgruebele

  • Posts: 55
Thanks Ian and mb_soft!

The problem phone is a Huawei Honor Note 8 with Android 8.0.  Switching to AudioTrack in combination with changing some of the buffer settings definitely improves things.  I will post back if I see further problems.

My current settings are as follows:

            Bass.BASS_SetConfig(BASSConfig.BASS_CONFIG_UPDATEPERIOD, 50);
            Bass.BASS_SetConfig(BASSConfig.BASS_CONFIG_UPDATETHREADS, 1);

            Bass.BASS_SetConfig(BASSConfig.BASS_CONFIG_BUFFER, 300);

            Bass.BASS_SetConfig(BASSConfig.BASS_CONFIG_DEV_PERIOD, 30);
            Bass.BASS_SetConfig(BASSConfig.BASS_CONFIG_DEV_BUFFER, 30 * 2);

            // for Honor Note 8:
            var alternateFlags = BASSInit.BASS_DEVICE_AUDIOTRACK;

-Philip