Topic: BASS_StreamCreateFileUser broken on Windows 20H1

[Mokhtar]

It seems that our App that was working happily on the current stable windows version is now acting up when we tried it, unchanged on the insider preview (20H1).

In particular, our call to BASS_StreamCreateFileUser (With buffer or buffer push) does not return until it has buffered 100x more bytes than it used to on the previous Windows version , which means the audio play back get significantly delayed and its own thread is blocked until it is done. Now it waits until it got about 104MB to return.

I checked the latency, min buffer, and min rate values reported by BASS on both versions on Windows and they are identical.

Does anybody have any info about what could have caused that change of behavior and what can be done about it?

Thank you.

[Ian @ un4seen]

I don't think BASS/add-on decoder buffering should be affected by any changes in Windows, but perhaps the Media Foundation stuff is. What file format are you playing, and what "ctype" value do you get from BASS_ChannelGetInfo? Does the problem happen even with WAV/MP3/OGG? Please also try BASS_StreamCreateURL (which uses the same buffered file system as BASS_StreamCreateFileUser) for comparison.

[Mokhtar]

We are playing AAC (mp4a) and MPEG. The Ctype is BASS_CTYPE_STREAM_MF. These are the two I know are failing (delayed) for sure on 20H1.

Playing an MP4 file works perfectly fine. Also using SteamCreateURL works fine as well on 20H1 for AAC. So it appears that the problem mainly happens with StreamCreateFileUser and MPEG codecs.

[Mokhtar]

Actually, it looks like SteamCreateURL is NOT working fine on furthe re-runs. I might have got that working by accident or in the wrong configruation.

[MB_SOFT]

Load BASS_AAC as plugin and your problem is solved.

[Ian @ un4seen]

We are playing AAC (mp4a) and MPEG. The Ctype is BASS_CTYPE_STREAM_MF. These are the two I know are failing (delayed) for sure on 20H1.

That looks like it is indeed something specific to Media Foundation then. Please upload an affected file to have a look at here:

   ftp.un4seen.com/incoming/

Also confirm that you are using the latest BASS version (and try upgrading if not).

[Mokhtar]

Load BASS_AAC as plugin and your problem is solved.

That sounds like a good thing to try. Unfortunately, when I try to load the "bass_aac.dll" plugin the same way we are loading the basshls.dll plugin, I get a BASS_ERROR_FILEOPEN error. I've confirmed that it's got the correct path to the file. Does it have any limitations that prevent it from loading in a UWP app?

That looks like it is indeed something specific to Media Foundation then. Please upload an affected file to have a look at here:

   ftp.un4seen.com/incoming/
Also confirm that you are using the latest BASS version (and try upgrading if not).

I just updated to latest BASS as an early step in troubleshooting this. The audio I'm playing is just streamed from a URL, in this case live channels from IHearRadio. I can PM you specific a specific sample URL if that would help.

[Ian @ un4seen]

Load BASS_AAC as plugin and your problem is solved.

That sounds like a good thing to try. Unfortunately, when I try to load the "bass_aac.dll" plugin the same way we are loading the basshls.dll plugin, I get a BASS_ERROR_FILEOPEN error. I've confirmed that it's got the correct path to the file. Does it have any limitations that prevent it from loading in a UWP app?

There isn't currently a UWP (WinStore) version of the BASS_AAC add-on, as it shouldn't be necessary due to the presence of Media Foundation codecs.

Is the problem only happening on UWP? If you haven't already done so, please also try regular "desktop" Windows.

The audio I'm playing is just streamed from a URL, in this case live channels from IHearRadio. I can PM you specific a specific sample URL if that would help.

Yes, please do. If not all streams are affected then also provide an unaffected one for comparison.

[Mokhtar]

Our app is UWP-only, so that's where we are seeing it. We don't have a desktop version of it to try with. I did however see that other BASS apps worked fine 20H1, but they were not UWP and have bundled the AAC plugin. So, from my understanding, this means they did not use the possibly faulty Media Foundation codecs.

I PM'ed you two streams as requested.

Thanks.

[Ian @ un4seen]

Comparing the URLs that you provided, I notice the one that you say is affected is HEv2 (Parametric Stereo) while the fine one is HEv1. Is it the case that all HEv2 streams are affected and all others are fine? The first stream is also ADTS while the second isn't, so perhaps it's all ADTS streams? If unsure, you could check an ADTS HEv1 stream.

To quickly check things on desktop Windows, you could try the pre-compiled CONTEST.EXE example that's included in the BASS package (C\BIN folder). That will use Media Foundation to play AAC streams. If that works fine then please confirm what BASS_SetConfig settings you're using in your app, and does leaving them at defaults make any difference?

[Mokhtar]

I am not familiar with HEv2 or ADTS, but if have sample URLs that you want me to test on 20H1, please just send them to me or let me know where to find them and I'll report the results I get.

I tried running using Contest.exe on the 20H1 device, apparently it has the same issue, a bit worse. On the first run, it froze for a couple of minus (similar to what we had in UWP), then crashed. On the second run, it took the same few minutes then actually started playing the audio. I then reran the exact command on another device with older windows and it played just fine within a few seconds.

So, the issue is reproducible with Contest as well which I believe rules out bad configuration on our app's side.

Let me know if you have any further suggestions.

Thank you.

[Ian @ un4seen]

Here are a few Shoutcast AAC streams (taken from directory.shoutcast.com)  for you to try for comparison:

   http://192.99.38.174:9342/stream
   http://212.129.1.171:8000
   http://111.223.51.8:8005

Let me know if which (if any) the problem happens with.

[Mokhtar]

I tested all three and all of them showed the same problem. I also verified that they worked fine on older non-20H1 machines.
Does that mean it's a general AAC issue? If so, is there a way to get a port of the AAC plugin for UWP, or is that a big undertaking beyond just a simple build?

[Ian @ un4seen]

It looks like all ADTS AAC streams are affected then. I will try to find out what's changed in Media Foundation and then get back to you (hopefully with an update to try).

[Ian @ un4seen]

It looks like Media Foundation in the Windows 20H1 preview is pre-reading at least 1MB of data from headerless file formats (eg. ADTS rather than MP4) when in asynchronous mode (which BASS currently uses for internet/buffered streams). I'm not sure if that's a bug that will be fixed or if it's here to stay, but here's a BASS update that should prevent it:

   www.un4seen.com/stuff/bass.zip

Let me know if you still see the problem happening with that.

[MB_SOFT]

If so it's a regression for Windows. I hope someone will report the problem to Microsoft.

[Mokhtar]

It looks like Media Foundation in the Windows 20H1 preview is pre-reading at least 1MB of data from headerless file formats (eg. ADTS rather than MP4) when in asynchronous mode (which BASS currently uses for internet/buffered streams). I'm not sure if that's a bug that will be fixed or if it's here to stay, but here's a BASS update that should prevent it:

   www.un4seen.com/stuff/bass.zip

Let me know if you still see the problem happening with that.

Thank you, a quick initial test shows that this is not getting stuck in the same place. We'll do further testing and see if we hit the same or similar issues with different streams.

If so it's a regression for Windows. I hope someone will report the problem to Microsoft.

We have reported this to Microsoft already.

[Ian @ un4seen]

I think I've found a nicer solution. The update above was refusing the pre-reading request, but here's one that seems to prevent the pre-reading request happening at all:

   www.un4seen.com/stuff/bass.zip

[Mokhtar]

I think I've found a nicer solution. The update above was refusing the pre-reading request, but here's one that seems to prevent the pre-reading request happening at all:

   www.un4seen.com/stuff/bass.zip

This has worked really well and passed our audio tests. On behalf of Amazon Alexa, thank you Ian for helping us keep the audio experience great for our customers. It is greatly appreciated.

[Ian @ un4seen]

Excellent. Let me know if you need a UWP version of the update too.

[Pete]

Hi Ian,

My name is Pete and I work with Mokhtar at Amazon.  One of the scans of the updated BASS package that we obtained as part of this issue and subsequent fix showed inclusion of the FAAD2 component, which is dual-licensed under GPL and a commercial license. 

Can we engage in an offline discussion about licensing of this component?

[Ian @ un4seen]

The FAAD2 library is used by the BASS_AAC add-on, but not BASS itself. By default, BASS will use the AAC decoder that comes with Windows. When using the BASS_AAC add-on, the FAAD2 library needs to be licensed from Nero separately, and if I recall correctly, Amazon did that many years ago for another product that was using the BASS_AAC add-on. It doesn't sound like you're using the BASS_AAC add-on in this case though, as this thread is regarding Windows' AAC decoder. If BASS_AAC has now appeared, perhaps it was just for testing/comparison purposes?

[StephBel]

Hello @Ian,

Concerning Windows with AAC streams (we cannot use the AAC library).

We made a workaround that is working with version 2.4.15.0.
But now we would need to use the last release to have access to BASS_ATTRIB_VOLDSP and BASS_ATTRIB_VOLDSP_PRIORITY, but we are still receiving an error when we call BASS_ChannelGetLength and BASS_ChannelSetPosition on:
BASS_ChannelGetLength(handle, BASS_POS_BYTE); return -1
and the BASS_ErrorGetCode is BASS_ERROR_NOTAVAIL
also the BASS_ChannelSetPosition(handle, 0, BASS_POS_BYTE); return false with value of BASS_ErrorGetCode BASS_ERROR_POSITION

So we are stuck with version 2.4.15.0.

[Ian @ un4seen]

Please upload (or link) an affected file to have a look at here:

   ftp.un4seen.com/incoming

Also confirm how you're creating the stream from it (BASS_StreamCreateFileUser?), and the Windows version if that makes a difference.

[StephBel]

yes:
ret = BASS_StreamCreateFileUser(STREAMFILE_NOBUFFER, flags, &fileprocs, RAMFileStruct);
 
flags are  BASS_STREAM_DECODE | BASS_STREAM_PRESCAN | BASS_SAMPLE_FLOAT | BASS_SAMPLE_SOFTWARE | BASS_UNICODE
 
BASS_FILEPROCS fileprocs = { RAMFileCloseProc, RAMFileLenProc, RAMFileReadProc, RAMFileSeekProc };

I have Windows 11.