Topic: BASS for Universal Windows Platform (UWP)

[Jfarro]

Ok, got a new question.

I'm using the store StorageFolder/StorageFiles to navigate to the Music directory.  I also specify access to the Music folder in my Manifest.  Essentially I should have full access to the music folder.

I bind to the storagefiles into a listbox, and on click I call Initialize and then StreamCreateFile

This looks like:
StorageFile selected = (StorageFile)SongList.SelectedItem;
            string songPath = selected.Path;

            Button action = (Button)sender;

            switch (action.Name)
            {
                case "PlayButton":
                    {                    
                        player.PlaySong(selected.Path); //player is a class I wrapped Bass.net in.
                        break;
                    }
                
            }

The path ends up in the format: "C:\\Users\\Joseph\\Music\\Jessie J\\Sweet Talker (Deluxe Version)\\01 Ain't Been Done.mp3"

This calls into:

        public bool PlaySong(string PathToSong)
        {
            int stream = Bass.BASS_StreamCreateFile(PathToSong, 0, 0, BASSFlag.BASS_DEFAULT);
            return Bass.BASS_ChannelPlay(stream, false);
        }

I get the error:
Bass.BASS_ErrorGetCode()
BASS_ERROR_FILEOPEN

I can play the file outside of Bass.net.  If I am in the debugger and try to call StreamCreateFile against other paths, I get the same error. However, if I call it against a song that is relative to bass.dll (essentially into my appx directory) then everything works great.

This is on Win10 X64 in a UWP project VS 2015 Update 1.

Update: I tried simplifying the file name to just 'track1.mp3', as well as loading other songs, with no luck. The songs work in media player outside of bass.net, but I understand that removes a boatload of variables when talking Store App development.

Any ideas?

[Ian @ un4seen]

I believe the issue there is that BASS is currently using the Win32 file functions, which are restricted to the app's own directories in Windows Store apps. To access other directories (eg. the user's Music directory), the Windows Store APIs need to be used, eg. the StorageFile class. Here's a slightly experimental BASS update that does use that stuff for file access:

   www.un4seen.com/stuff/bass-winstore-test.zip

Note that the Windows Store APIs need to be used asynchronously, ie. not in the main/UI thread. So you will now need to call BASS_StreamCreateFile asynchronously. For example, something like this:

Code: [Select]

Task.Run(() =>
{
stream = Bass.BASS_StreamCreateFile(PathToSong, 0, 0, BASSFlag.BASS_DEFAULT);
Bass.BASS_ChannelPlay(stream, false);
});

This update hasn't been tested much yet, so please report how you get on with it.

[Jfarro]

Thanks! Yeah that's exactly what I was seeing. My temp workaround was to copy the files using storagefile and then load them so I could continue dev (and also to make sure I wasn't doing something dumb).  I'm super stoked you were able to track that down. And I'm happy to be the tester on this, it's super valuable

I'll give this a try tonight and report back, thanks a ton!

[Jfarro]

Some more updates:
1) The fix to the file load appears to work, I'm now able to use storage apis to load from various places that the user gets access (I'm using the fileopendialog to browse and try various places). This is great

2) When I thought about the previous bug, I realized it'd be worth scanning the api set using the Application Certificatin kit to ensure all apis in BASS are 'store compliant'.  I hit the following errors which are being called in the WindowsStore.dll, which would prevent an app from being put in the store currently:

◦API BASS_ChannelGetLevelEx in bassmix.dll is not supported for this application type. Bass.Net.WinStore.dll calls this API.
◦API BASS_Mixer_ChannelFlags in bassmix.dll is not supported for this application type. Bass.Net.WinStore.dll calls this API.
◦API BASS_Mixer_ChannelGetData in bassmix.dll is not supported for this application type. Bass.Net.WinStore.dll calls this API.
◦API BASS_Mixer_ChannelGetEnvelopePos in bassmix.dll is not supported for this application type. Bass.Net.WinStore.dll calls this API.
◦API BASS_Mixer_ChannelGetLevel in bassmix.dll is not supported for this application type. Bass.Net.WinStore.dll calls this API.
◦API BASS_Mixer_ChannelGetMatrix in bassmix.dll is not supported for this application type. Bass.Net.WinStore.dll calls this API.
◦API BASS_Mixer_ChannelGetMixer in bassmix.dll is not supported for this application type. Bass.Net.WinStore.dll calls this API.
◦API BASS_Mixer_ChannelGetPosition in bassmix.dll is not supported for this application type. Bass.Net.WinStore.dll calls this API.
◦API BASS_Mixer_ChannelGetPositionEx in bassmix.dll is not supported for this application type. Bass.Net.WinStore.dll calls this API.
◦API BASS_Mixer_ChannelRemove in bassmix.dll is not supported for this application type. Bass.Net.WinStore.dll calls this API.


Let me know if you need help reproing this. The app certication kit for me was located at: :\Program Files (x86)\Windows Kits\10\App Certification Kit

[Ian @ un4seen]

Good to hear that the new file reading stuff is working well for you.

Regarding the Certification Kit issue, are you currently including BASSMIX.DLL in your app? If not, I guess the Certification Kit may be detecting that those functions are called somewhere in BASS.Net, but it can't see that those code paths aren't actually used in your app. I don't seem to be able to reproduce the problem here though, if I create my own little test app that uses BASS.Net without BASSmix, so I'm not really sure. Does adding BASSMIX.DLL to your project remove the problem?

I did see that the x86 DLLs are currently failing that API test though, due to the compression system. I will see if that can be tweaked, but in the meantime non-compressed x86 DLLs are now up in the package in the 1st post.

[Jfarro]

Interesting...adding bassmix.dll to my project fixed it. I don't call into BassMix at all.  The errors were reporting it as if it was coming from the store.dll.  Also I was building debug...I've switched to release with the latest build you dropped and confirmed no errors in the x64 build. I'll continue to work and add in the others when I get closer to release.

Thanks again for quick responses, this is looking good.

[Ian @ un4seen]

Good to hear that adding BASSMIX.DLL to your project fixed the problem, even if I'm not sure why it would! Did you also try a Release build without BASSMIX.DLL? If not, that could be worth a try, as the Certification Kit does say that it shouldn't be used on Debug builds.

[Jfarro]

I'll give that a shot and report back.

A few new  bugs now that I'm getting deeper into the APIs...these were found with the x64 drop with the file path (StorageFile) fix from the thread:

1) Trying to play a mod file is failing.  Bass_MusicLoad is returning 0, and ErrorGetCode is returning BASS_ERROR_MEM. I thought I'd hit this with midi, but can't get a repro due to bug #2 that I'm seeing

2) When trying to play a midi, it wants a soudnfont set.  When I call Bass_MIDI_FontInit(myPath) it's throwing an exception.  The inner exception is null, and the message returned is simply: "External component has thrown an exception."

The exception source is Bass.Net.Winstore

The stack points to: Un4seen.Bass.AddOn.Midi.BassMidi.BASS_MIDI_FontInitUnicode(String file, BASSFlag flags)\r\n   at MusicPlayer.MusicPlayer.SelectSoundFont(String SoundFont)"

Let me know if that helps.  I'll keep plugging away..I'm working on writing a store friendly visualization currently.

[Ian @ un4seen]

1) Trying to play a mod file is failing.  Bass_MusicLoad is returning 0, and ErrorGetCode is returning BASS_ERROR_MEM. I thought I'd hit this with midi, but can't get a repro due to bug #2 that I'm seeing

Ah yes, BASS_MusicLoad isn't working with the new Windows Store file stuff because it currently requires memory-mapped file support, which doesn't appear to be available in the Windows Store file APIs. An update to get around that is now up in the package in the 1st post.

2) When trying to play a midi, it wants a soudnfont set.  When I call Bass_MIDI_FontInit(myPath) it's throwing an exception.  The inner exception is null, and the message returned is simply: "External component has thrown an exception."

BASS_MIDI_FontInit seems to be working OK here. Are you calling it asynchronously? If not, please try that. As it internally opens a file (the soundfont), BASS_MIDI_FontInit calls will need to be asynchronous like BASS_StreamCreateFile/etc.

[Jfarro]

I've loaded up the new version and confirmed that Mp3s, Mods, and Midis from various folders are working now. You were correct on the soundfont loading...I wasn't loading it async..once I changed that things started working again.  I also verified the behavior of having soundfonts with the .sf2 extention in the same folder 'autoload'.  Looking great now!

I'll move on to the getData() methods and work on a simple visualizer. Merry Christmas/Happy Holidays!

[Foriero]

Ian, would it be possible to have x86 and x64 compiled against Microsoft Visual C++ 2015 Runtime Package?

We have Unity3D project that depends on it and as I guess we can not have 2013 and 2015 Runtime packages parallel in one VS project, right?

Our project simple Load and then immediately Unload bass.dll, bassmidi.dll and bassmix.dll because there is for sure some init problem.

We are addressing latest windows 10 sdk and we are visual studio 2015 update 1.

Our project is completely windows 10 only.

I'm also not sure if we can use Phone midi and mix dll for latest windows 10 arm build. Unfortunately I don't have arm device but will try it in simulator at least.

Anyway we are happy with this port and looking forward to have it working for our Music School project :-) http://www.foriero.com/pages/music-school.php

Please let me know thank you and calm holidays.

[Ian @ un4seen]

I seem to recall that it was possible to use both the VS2013 and VS2015 runtimes at the same time when I last checked; they have different filenames, so there ought not to be a problem. The Windows Phone add-on DLLs also did work on ARM Windows 10. A separate BASS.DLL was only needed because 1 or 2 imported functions have been moved to different DLLs in Windows 10. Let me know if do encounter a problem in either case, and I'll check that stuff again.

[Marek Ledvina]

Hi Ian, I tried to include both VS2013 and VS2015 and regretfully it does not like each other. I mean other components do not like it. Our game is running but many fold times slower. Would it be possible to get that WIN 10 version only?

[Ian @ un4seen]

That's strange. Here are x86/x64 Windows 10 builds for you to try:

   www.un4seen.com/stuff/bass-winstore-test.zip

Let me know whether it helps.

[Marek Ledvina]

Hi Ian,

Seems like we passed the BASS initialization without errors and also loaded SF2 but seems there is some issue with threads. Since we now mix bass.dll (2015) with bassmidi.dll (2013) and bassmix.dll (2013)

May I ask you also compile midi and mix against 2015?

We have a lot of these but before with 2013 bass.dll we had also exceptions now we are without exceptions which is a step forward :
The thread 0x968 has exited with code 0 (0x0).
The thread 0x1f98 has exited with code 0 (0x0).
The thread 0x1b64 has exited with code 0 (0x0).
The thread 0x22d0 has exited with code 0 (0x0).
The thread 0x1114 has exited with code 0 (0x0).
The thread 0x26a8 has exited with code 0 (0x0).
The thread 0x162c has exited with code 0 (0x0).
The thread 0x1d04 has exited with code 0 (0x0).
The thread 0x454 has exited with code 0 (0x0).
The thread 0x137c has exited with code 0 (0x0).
The thread 0x42c has exited with code 0 (0x0).
The thread 0xe68 has exited with code 0 (0x0).
The thread 0x17a8 has exited with code 0 (0x0).
The thread 0x11e4 has exited with code 0 (0x0).
The thread 0x1624 has exited with code 0 (0x0).
The thread 0x1244 has exited with code 0 (0x0).
The thread 0x64c has exited with code 0 (0x0).
The thread 0x1b74 has exited with code 0 (0x0).
The thread 0x1084 has exited with code 0 (0x0).
The thread 0x8f4 has exited with code 0 (0x0).

Thank you very much, Marek.

[Ian @ un4seen]

OK. Windows 10 x86/x64 builds of BASSMIDI/mix have now been added for you to try:

   www.un4seen.com/stuff/bass-winstore-test.zip

[Jfarro]

I think I found a new bug:
static string BASS_ChannelGetMusicName(
   int handle
)
When passing in MOD's that have normal names using XMPlay, into this API I'm getting back what looks to be Chinese characters. I'm wondering if there is a parsing error.  None of the mod files I've tried have returned a correct name.

Overall, things I've tried which are working great:
Midis, including soundfonts
MP3s, including getchannelinfo, and all of the getchanneldata stuff
Mod playback, including ST3 and XM files
Get/Set position apis
Start/Stop APIs
Tag querying for MP3s

[rv]

What is the lowest latency can you get with soundfonts?

[Ian @ un4seen]

I think I found a new bug:
static string BASS_ChannelGetMusicName(
   int handle
)
When passing in MOD's that have normal names using XMPlay, into this API I'm getting back what looks to be Chinese characters. I'm wondering if there is a parsing error.  None of the mod files I've tried have returned a correct name.

That's strange. BASS_ChannelGetMusicName isn't actually a BASS function, but rather a function provided for convenience by BASS.Net, which internally calls BASS_ChannelGetTags with tags=BASS_TAG_MUSIC_NAME and then converts the result to a .Net string. I checked the BASS_TAG_MUSIC_NAME tag in C++ just now, and it seemed to be fine, so perhaps something is going wrong in the string conversion in BASS_ChannelGetMusicName. Are the other MOD music tag helper functions (BASS_ChannelGetMusicMessage/Sample/Instrument) similarly affected?

Overall, things I've tried which are working great:
Midis, including soundfonts
MP3s, including getchannelinfo, and all of the getchanneldata stuff
Mod playback, including ST3 and XM files
Get/Set position apis
Start/Stop APIs
Tag querying for MP3s

Great

What is the lowest latency can you get with soundfonts?

Soundfonts don't directly affect latency. The lowest possible latency will be determined by the device buffer length, which can be set via the BASS_CONFIG_DEV_BUFFER option. The default in the Windows Store version is currently 30ms. I quickly tried setting it to 20ms just now and that seemed to be fine, but CPU load was low (a higher load might need a bigger buffer to avoid breaks in the sound).

[rv]

Is 5ms or 10ms possible with Windows Store Apps, like with with Desktop Wasapi exclusive ?

[Jfarro]

Hmm. It looks like the names are coming back as Ansi, but Bass.Net is using Unicode to read them (I'm guessing based on this)


IntPtr h = Bass.BASS_ChannelGetTags(handle, BASSTag.BASS_TAG_MUSIC_NAME);
System.Runtime.InteropServices.Marshal.PtrToStringAnsi(h)

Returns the correct name "the brewery" from the file I'm reading.  However:

System.Runtime.InteropServices.Marshal.PtrToStringUni(h)

Returns what I'm seeing using the getmusicname method: "桴\u2065牢睥牥yˋ\u0004é"

[Ian @ un4seen]

Is 5ms or 10ms possible with Windows Store Apps, like with with Desktop Wasapi exclusive ?

Exclusive mode output is available to Windows Store apps (except on Windows Phone I believe), but it isn't currently supported by BASS. I will look into that soon. In the meantime, 20ms appears to be the lowest possible in shared mode, eg. Windows will still use 20ms if 10ms is requested.

Hmm. It looks like the names are coming back as Ansi, but Bass.Net is using Unicode to read them (I'm guessing based on this)


IntPtr h = Bass.BASS_ChannelGetTags(handle, BASSTag.BASS_TAG_MUSIC_NAME);
System.Runtime.InteropServices.Marshal.PtrToStringAnsi(h)

Returns the correct name "the brewery" from the file I'm reading.  However:

System.Runtime.InteropServices.Marshal.PtrToStringUni(h)

Returns what I'm seeing using the getmusicname method: "桴\u2065牢睥牥yˋ\u0004é"

Yep, it does seem like that's the case. I will check with the BASS.Net developer.

[Jfarro]

Is there any way to enable Background Audio with Bass in UWP? I've got a thread over on the UWP forums on MSDN to see if I can extend the MediaPlayer class. Barring that,  my other thought would be to try to use the Bass library to transcode the audio to a stream and feed it to a media element...is that in a Bass API by chance?

I could hand off most of the formats to media player...I think the two I'd be stuck on are the .midi (along with the soundfont I'm loading) and the .mod's. 

I'll poke around and see if I can come up with something, but figured worth asking here in case someone's already solved this.

[Lukas]

@Ian:

Here are two links regarding background playback, you might want to check out:

https://blogs.windows.com/buildingapps/2014/05/15/real-time-audio-in-windows-store-and-windows-phone-apps/

https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/WindowsAudioSession

The first one has an interesting sentence: "Only render stream categories set to AudioCategory_BackgroundCapableMedia or AudioCategory_ForegroundOnlyMedia support offloading." Setting AudioCategory_BackgroundCapableMedia on the WASAPI channel might enable background audio on the phone. The second one is a Windows 10 sample with background capable WASAPI playback. Not sure if that can be easily transferred to WP81, but might be worth to take a look.

If all this does not work, it might be that MS requires you to use the BMP for background audio on the phone. Then the only way would be to feed the final sample data into the BackgroundMediaPlayer. A MediaStreamSource can be created which allows you to feed decoded samples into the MF engine hosted by BMP. This should definitely work, code samples are available for that as well (https://code.msdn.microsoft.com/windowsapps/MediaStreamSource-media-dfd55dff).

It would be great if you could also enable hardware offloading on the phone, since this might considerably reduce the battery usage on the phone during playback (the first link talks about that).

[Ian @ un4seen]

Is there any way to enable Background Audio with Bass in UWP? I've got a thread over on the UWP forums on MSDN to see if I can extend the MediaPlayer class. Barring that,  my other thought would be to try to use the Bass library to transcode the audio to a stream and feed it to a media element...is that in a Bass API by chance?

What platform/architecture are you testing on? Background audio seems to be working OK here with BASS in Windows Store apps, eg. I can switch to another app and the BASS output is still heard. Background audio on Windows Phone is currently a mystery though. There was some discussion on that earlier in this thread, here:

   www.un4seen.com/forum/?topic=16665.msg117522#msg117522

Here are two links regarding background playback, you might want to check out:

https://blogs.windows.com/buildingapps/2014/05/15/real-time-audio-in-windows-store-and-windows-phone-apps/

https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/WindowsAudioSession

The first one has an interesting sentence: "Only render stream categories set to AudioCategory_BackgroundCapableMedia or AudioCategory_ForegroundOnlyMedia support offloading." Setting AudioCategory_BackgroundCapableMedia on the WASAPI channel might enable background audio on the phone. The second one is a Windows 10 sample with background capable WASAPI playback. Not sure if that can be easily transferred to WP81, but might be worth to take a look.

If all this does not work, it might be that MS requires you to use the BMP for background audio on the phone. Then the only way would be to feed the final sample data into the BackgroundMediaPlayer. A MediaStreamSource can be created which allows you to feed decoded samples into the MF engine hosted by BMP. This should definitely work, code samples are available for that as well (https://code.msdn.microsoft.com/windowsapps/MediaStreamSource-media-dfd55dff).

Unfortunately, just using the AudioCategory_BackgroundCapableMedia category isn't enough to get background audio working on Windows Phone.

Regarding the MediaStreamSource stuff, I haven't tried that myself, but if you would like to give it a try, you could use the BASS_STREAM_DECODE flag (eg. in a BASS_StreamCreateFile call) to create a "decoding channel" and then call BASS_ChannelGetData to get sample data from it as needed for playback.