Topic: BASS for Universal Windows Platform (UWP)

[Jfarro]

On a Surface Pro 3 running Windows 10 using an X64 build which I submitted to the store, I have the audio 'stopping' when my app is minimized. I haven't built an audio app for the store before, so perhaps I'm missing something. When I researched it I found the background audio samples mentioned, and started to try to implement that. That's when I found the backgroundmediaplayer, and realized that I was hitting issues.

I'll look into mediastreamsource, as that seems like a handy thing to have/do regardless.  I haven't tried any of this on a phone yet, figured I'd finish a desktop version and then move onto that.

[Ian @ un4seen]

Oh right, you're minimizing. Does your app also get muted if you just switch focus to another app without minimizing it? Microsoft's WindowsAudioSession example (which is meant to support background audio) is also getting muted when minimized, so I think that is just the way it is for Windows Store apps; have you seen other apps that don't get muted when minimized?

[RJJatson]

Where do i find BPMCounter class on this new windows store library?
i cant found the misc,
if i really cant, is there any workaround to implement .NET4.0 on windows store apps?

[radio42]

No, that class is unfortunately not available in the WinStore version due to the .Net framework limits...

[Lukas]

Oh right, you're minimizing. Does your app also get muted if you just switch focus to another app without minimizing it? Microsoft's WindowsAudioSession example (which is meant to support background audio) is also getting muted when minimized, so I think that is just the way it is for Windows Store apps; have you seen other apps that don't get muted when minimized?

All audio player apps continue playback when minimized. That is what "background playback" is all about. You can check out my player "Music Mode" if you need an example, but probably every app that calls itself "music player" will have that working.

It is surprising to hear that the sample also does not work when minimized. I will check this out myself. The sample description explicitly talks about background playback, it would be weird if that does not work.

[Lukas]

I just tried the sample and indeed the background playback does not work. That's pretty weird since this is explicitly part of the sample. I already found one bug in the sample (background audio declaration missing in appxmanifest), but after fixing this, it still did not work. I have asked for help in the msdn forums, will report back if I find out more.

[Jfarro]

I think I found a cool way to handle the various dlls for Bass without csproj hacks (I was having problems with those)

I placed this into my post build, and then placed the files in Assets\libs\  folders with x86, x64, and arm subfolders.
I'm still working to understand if they need to be in the appx folder of the parent, and if this will be ok to submit to the store.

xcopy $(ProjectDir)Assets\Libs\$(PlatformName)\Bass.dll  $(TargetDir)Bass.dll /y
xcopy $(ProjectDir)Assets\Libs\$(PlatformName)\Bass.dll  $(TargetDir)Appx\Bass.dll /y
xcopy $(ProjectDir)Assets\Libs\$(PlatformName)\Bassmidi.dll  $(TargetDir)Bassmidi.dll /y
xcopy $(ProjectDir)Assets\Libs\$(PlatformName)\Bassmidi.dll  $(TargetDir)Appx\BassMidi.dll /y
xcopy $(ProjectDir)Assets\Libs\$(PlatformName)\Bassmix.dll  $(TargetDir)Bassmix.dll /y
xcopy $(ProjectDir)Assets\Libs\$(PlatformName)\Bassmix.dll  $(TargetDir)appx\Bassmix.dll /y

The problem with the csproj way is that I wasn't able to use a single 'content' source but copy it to differnet directories...so bass.dll would end up in a subirectory and didn't seem to be found.  For instance if bass.net ended up in Assets\bass.dll using content and 'copyifnewer', then It'd fail on load for me.

I'll reply back if this works and can be distributed in the store.

[Jfarro]

Followup: the above is working for Win32 apps, however it is NOT working for windows phone.

If I copy Bass.dll using the content attribute and have it under 'assets', it gets copied to a subfolder called 'assets' however and then it seems it can't be found.  However if I manually copy it from assets to the root appx folder of my project, things work.

I can't find a way to have the dll in the assets folder, but have it get copied to the root, without doing some post build step.  Anyone have luck getting this working for phone AND 64/32 bit in a single project?

[Ian @ un4seen]

I'm not sure about putting the DLLs in the Assets folder (I haven't got that working), but the CSPROJ modification method seems to be working for me. What problems did you encounter when you tried it? Note you only need to do that stuff for the native BASS DLLs, not for the BASS.Net DLL (just add a reference to that).

[Jfarro]

To answer the csproj question...from what I can see I'd have to have the x86 bass dll in the root of my project to get it to copy to the root where the winstore dll seems to want it.  This seems to be the same for the 64 bit..since I can't have two bass.dll's in the same folder, I'm a bit confused.  I have a feeling either I'm doing something wrong there, or I'm misunderstanding.

I tried saying 'if its x86 then get the bass.dll from assets\x86\bass.dll but it copies it to assets\x86\bass.dll. Since the Bass.net.Winstore isn't in the same directory things seem to blow up.  Let me know if that makes sense.


Also, on release x64 I'm seeing:
An exception of type 'System.TypeLoadException' occurred in AMP3.Interop.dll but was not handled in user code

Additional information: Unresolved P/Invoke method 'BASS_PluginLoadUnicode!bass.dll' in assembly 'Bass.Net.WinStore, Version=2.4.11.2, Culture=neutral, PublicKeyToken=8f2d676939c2ea9e' because it is not available in UWP applications. Please either use an another API , or use [DllImport(ExactSpelling=true) to indicate that you understand the implications of using non-UWP application APIs.

If there is a handler for this exception, the program may be safely continued.

[Jfarro]

To answer the csproj question...from what I can see I'd have to have the x86 bass dll in the root of my project to get it to copy to the root where the winstore dll seems to want it.  This seems to be the same for the 64 bit..since I can't have two bass.dll's in the same folder, I'm a bit confused.  I have a feeling either I'm doing something wrong there, or I'm misunderstanding.

I tried saying 'if its x86 then get the bass.dll from assets\x86\bass.dll but it copies it to assets\x86\bass.dll. Since the Bass.net.Winstore isn't in the same directory things seem to blow up.  Let me know if that makes sense.


Also, on release x64 I'm seeing:
An exception of type 'System.TypeLoadException' occurred in AMP3.Interop.dll but was not handled in user code

Additional information: Unresolved P/Invoke method 'BASS_PluginLoadUnicode!bass.dll' in assembly 'Bass.Net.WinStore, Version=2.4.11.2, Culture=neutral, PublicKeyToken=8f2d676939c2ea9e' because it is not available in UWP applications. Please either use an another API , or use [DllImport(ExactSpelling=true) to indicate that you understand the implications of using non-UWP application APIs.

If there is a handler for this exception, the program may be safely continued.

Update: The second x64 release issue disappeared when I directly added the dlls as content to the project..this makes me suspect the xcopy is a bad idea.  I'll go back and try the project method again.

[Ian @ un4seen]

To include the BASS/BASSMIDI/BASSmix DLLs in a "Universal Windows" app, the CSPROJ additions should look something like this:

Code: [Select]

  <ItemGroup Condition="'$(Platform)' == 'x86'">
    <Content Include="<basspath>\Windows 8\x86\bass.dll">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
    <Content Include="<basspath>\Windows 8\x86\bassmidi.dll">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
    <Content Include="<basspath>\Windows 8\x86\bassmix.dll">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
  </ItemGroup>
  <ItemGroup Condition="'$(Platform)' == 'x64'">
    <Content Include="<basspath>\Windows 8\x64\bass.dll">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
    <Content Include="<basspath>\Windows 8\x64\bassmidi.dll">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
    <Content Include="<basspath>\Windows 8\x64\bassmix.dll">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
  </ItemGroup>
  <ItemGroup Condition="'$(Platform)' == 'ARM'">
    <Content Include="<basspath>\Windows 10\arm\bass.dll">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
    <Content Include="<basspath>\Windows 10\arm\bassmidi.dll">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
    <Content Include="<basspath>\Windows 10\arm\bassmix.dll">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
  </ItemGroup>

Where "<basspath>" is replaced with the full path of where you extracted the Windows Store BASS package. Is that not working when you try it?

[Jfarro]

When I do that I hit problems on the x86 build (but x64 works great). I'm digging into it, but I'm starting to think this is because I got flighted to RS1, and that this is a windows platform issue I'm hitting. I'll look into it more tonight and reply back.  Also I found that if I put the dlls in the assets subfolder...the system copies the subfolder...but if I have them in say c:\libraries, then they get copied to root (which is what I was having problems with). 

I can tell from the x86 binary size that the correct file is being copied down.

Edit: After rolling back from an RS1 insider build, this is all working now. Note that when you switch from an x64 build to x86, your exception settings are not carried over...so if you've turned off unmanaged exceptions that pop up in x64 and switch...exceptions that seem 'new' may be the same, just with different projection configuration settings for that build flavor.

Thanks again Ian! Next up..I'm going to try to get Arm on wp10 going

[Jfarro]

I think I have a new bug...when trying to read WMA tags I'm getting back null.  I've tried:
Bass.BASS_ChannelGetTags(handle,BASSTag.BASS_TAG_WMA)
{0}

and   string[] tags = Bass.BASS_ChannelGetTagsWMA(handle);

The songs I'm querying have info that shows up in windows media player, and I see the artist, album info in properties. These are from ripped CD's using Windows Media Player, so I believe the info is accurate.

Other than that, I've verified that the handle is valid, and that the file plays.

[Ian @ un4seen]

The BASS_TAG_WMA tag type currently only applies when the BASSWMA add-on is used to play a WMA file. When the Media Foundation WMA codec is used, then the tags should be available via the BASS_TAG_MF tag type (or BASS_ChannelGetTagsMF with BASS.Net) instead.

[Jfarro]

Thanks Ian, I've confirmed that works.

I'm seeing really long load times with createfile and wma. I thought it was the tag querying.  Is there a different flag recommended for getting just the tag data from a mediafoundation/wma file?


Right now I'm just passing:   handle = Bass.BASS_StreamCreateFile(path, 0, 0, BASSFlag.BASS_DEFAULT);

I'm seeing 2 second to 12 second load times in debug.  In Release it's harder for me to benchmark currently, but the load times seem extremely long for only the wma file types. Ogg, Mp3, Mod, xm, IT, Midi, and even .sid using addons are all loading relatively speedy with the same codebase. I'm seeing this repro on 32 bit and 64 bit builds. Any ideas?

[Ian @ un4seen]

That's strange. Trying a few WMA files myself here, the BASS_StreamCreateFile call is taking under 200ms in each case. I'm not sure why it would be taking so long there. Are the files on a local drive? In my tests, they were in the user's "Music" folder. Are you having the problem with all WMA files or only particular ones, and does it happen every time you open those files or only sometimes, eg. perhaps the first time? If it's affecting particular WMA files, please upload one to try here:

   ftp.un4seen.com/incoming/

For comparison, are MP4/AAC files taking as long as WMA files? That could help to narrow down where the problem lies, as Media Foundation is used to decode them too.

[Jfarro]

I'm having trouble getting a solid repro.  I have the files in the music directory, alongside my mods, midis, and mp3 test files.  Today they seem to be loading fine. I brought in an mp4 to test, and using the MF for aac, m4a, and an mp4 test file I'm not seeing metadata.

While testing and debugging I thougth I had a repro, but then I restarted VS and it seemed to go away.  Yesterday I couldn't get it to not repro, but I have rebooted since then. I wonder if I'm getting my machine into a bad state.
The one other change was that I was loading the zxlib plugin, though I don't see how that'd affect MF stuff.

I'll explore a bit more, then if I can't get the metadata on the aac file I'll ftp that to you.  I'll also try to get that repro back.

[Ian @ un4seen]

I brought in an mp4 to test, and using the MF for aac, m4a, and an mp4 test file I'm not seeing metadata.

Did you use the BASS_TAG_MF tag type then? If so, please try BASS_TAG_MP4, as BASS will read MP4 tags itself (rather than Media Foundation doing it).

The one other change was that I was loading the zxlib plugin, though I don't see how that'd affect MF stuff.

That might explain it, as Media Foundation codecs are only tried after any plugins (loaded via BASS_PluginLoad) have been tried. So, for example, if the zxlib plugin is downloading a large part of the stream to have a look at, that would introduce a delay before Media Foundation gets a look at it. When you say "zxlib plugin" are you referring to BASSZXTUNE? Looking at the source code (v2.4.4), it doesn't look like it will download internet streams (it's rejecting BASSFILE_BUFFERED files), so the "downloading a large part of the stream" scenario shouldn't happen, but perhaps the code has since changed?

[Jfarro]

I got to work on this a bit more today. I've uploaded the file I was having problems with to your incoming share on the FTP.
File should be something like: Right Hand.m4a

Here's some of the API's I tried (Some just to see if anything would light up)


Bass.BASS_ChannelGetTagsMF(MusicHandle)
null
Bass.BASS_ChannelGetTagsMP4(MusicHandle)
null
Bass.BASS_ChannelGetTagsOGG(MusicHandle)
null
Bass.BASS_ChannelGetTagsWMA(MusicHandle)
null
Bass.BASS_ChannelGetTags(MusicHandle,BASSTag.BASS_TAG_MF)
{0}
Bass.BASS_ChannelGetTags(MusicHandle,BASSTag.BASS_TAG_MP4)
{0}

I verified that the return value from createchannel is non zero. The song actually plays...just the meta data doesn't seem to come back. This is from a Task.Run to keep things on a background thread.

[Ian @ un4seen]

Ah! I see now that BASS's MP4 tag reading hadn't been enabled in the Windows Store version ... An update with it enabled is now up in the 1st post.

[ken]

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:

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

Just tested on the new Raspberry Pi 3 with latest build of Win 10 IoT, BASS works great. Here is working code in C# for playing a web stream. I'm using the Windows Store version of BASS.Net

Please note that the built in sound card on the Pi is very noisy.

Code: [Select]


private void PlayStream()
{
            BassNet.Registration("your_email", "_your_reg_code");  //You must have this else you get an error and it will not run!

            Bass.BASS_Init(-1, 44100, Un4seen.Bass.BASSInit.BASS_DEVICE_DEFAULT, IntPtr.Zero);

 
            string _url = "http://stream.dbmedia.se/crr96";

            Task.Run(() =>
            {
                int handle = Bass.BASS_StreamCreateURL(_url,0, BASSFlag.BASS_DEFAULT, null, IntPtr.Zero);
                Bass.BASS_ChannelPlay(handle, false);
            });


        }



[Lightning]

to any Winstore/BASS developer-

I need some help with a Bass/Winstore issue.
In Debug mode, my app runs fine.  The problem is when I compile with the .net Native tool chain in Release mode all hell breaks loose
I have read every thread in help and the forum.
I think the issue is how .net tool chain is processing the bass .dlls
I am using six declarations from my program like this:
 // BASS_RecordInit
            [DllImport("bass.dll", ExactSpelling = true)]
            public static extern bool BASS_RecordInit(int device);
======================
however the compiler gives me these warnings for ALL uncalled functions:
1>C:\Program Files (x86)\MSBuild\Microsoft\.NetNative\x86\ilc\IlcInternals.targets(936,5): warning : ILTransform_0000:       MCG : warning MCG0006: Unresolved P/Invoke method 'BASS_SetDevice!bass.dll' in assembly 'Bass.Net.WinStore, Version=2.4.11.2, Culture=neutral, PublicKeyToken=8f2d676939c2ea9e' because it is not available in UWP applications. Please either use an another API , or use [DllImport(ExactSpelling=true) to indicate that you understand the implications of using non-UWP application APIs.
=====================
do all these need to be added as embedded resources under content?
bass.dll, bass.net.dll, bass.net.winstore.dll

Again, the baffling issue is that in Debug the App is fine.  .net tool chain compiles don't like something I did...

I appreciate JFarros explanation of how to set up an app, but if anyone else has the exact steps, perhaps I missed something...

[Ian @ un4seen]

I think the issue is how .net tool chain is processing the bass .dlls
I am using six declarations from my program like this:
 // BASS_RecordInit
            [DllImport("bass.dll", ExactSpelling = true)]
            public static extern bool BASS_RecordInit(int device);

Are you using "DllImport" to import BASS functions but also using BASS.Net? I don't think you need to bother with "DllImport" when using BASS.Net.

do all these need to be added as embedded resources under content?
bass.dll, bass.net.dll, bass.net.winstore.dll

You don't need bass.net.dll (I believe that's just for normal Windows), and I don't think the DLLs should be embedded resources. You should add a reference to bass.net.winstore.dll, and bass.dll (and any add-ons used) should be copied to the output directory, eg. like in this post:

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

I think another way to set that up is to use a "BeforeResolveReferences" target to copy the appropriate BASS DLLs for the target platform.

[Jfarro]

Ian, I may have a new bug...I'm trying to build in an EQ, and used the following:


 public int[] FXEQ = { 0, 0, 0 };

 private void SetBFX_EQ(int stream)
        {
            BASS_DX8_PARAMEQ eq = new BASS_DX8_PARAMEQ();
            FXEQ[0] = Bass.BASS_ChannelSetFX(stream, BASSFXType.BASS_FX_DX8_PARAMEQ, 0);
            FXEQ[1] = Bass.BASS_ChannelSetFX(stream, BASSFXType.BASS_FX_DX8_PARAMEQ, 0);
            FXEQ[2] = Bass.BASS_ChannelSetFX(stream, BASSFXType.BASS_FX_DX8_PARAMEQ, 0);
            eq.fBandwidth = 18f;
            eq.fCenter = 100f;
            eq.fGain = 0f;

            Bass.BASS_FXSetParameters(FXEQ[0], eq);
            eq.fCenter = 1000f;
            Bass.BASS_FXSetParameters(FXEQ[1], eq);
            eq.fCenter = 8000f;
            Bass.BASS_FXSetParameters(FXEQ[2], eq);
        }

When I call SetBFX_EQ on a valid stream, I get:

An unhandled exception of type 'System.PlatformNotSupportedException' occurred in Bass.Net.WinStore.dll

Additional information: Marshalling arbitrary types is not supported

Mod, Midi, getvalues, and other APIs work fine. I've tried this in both a Task.Run and outside of it, with no luck.  Any ideas?