next »

[stevenmmm]

i would like to use BASSWASPI such that resampling is avoided if the sample rate of the source data is supported by the device ie. use exclusive mode and set the device sample rate to that of the source data (this is for people who expect bit-perfect output). While I expect most music files will be 44100, some might have different sample rates. From what I can see the only way to play different sample rates (without resampling) is to free and re-initialise the device. Is that something you would advise against doing for any reason?

[Ian @ un4seen]

But my code hangs on BassWasapi.BASS_WASAPI_Lock(true);

It do work with just:

int _delay = BassWasapi.BASS_WASAPI_GetData(null, (int)Un4seen.Bass.BASSData.BASS_DATA_AVAILABLE);
_ts = TimeSpan.FromSeconds(Bass.BASS_ChannelBytes2Seconds(_channel1, BassMix.BASS_Mixer_ChannelGetPositionEx(_channel1, BASSMode.BASS_POS_BYTES, _delay)));

do I need BassWasapi.BASS_WASAPI_Lock(true) ? What does it do?

The purpose of the BASS_WASAPI_Lock call there is to prevent the mixer processing more data in the middle of the position calculations. For example, if the mixer did process some more data between the BASS_WASAPI_GetData and BASS_Mixer_ChannelGetPositionEx calls, that would invalidate the "_delay" value and result in an incorrect position being returned by BASS_Mixer_ChannelGetPositionEx.

Where are you calling that code from? I guess a timer in the main thread? Are you also using any callback functions (eg. DSPPROC/SYNCPROC), and if so, what are they doing, eg. any GUI stuff?

i would like to use BASSWASPI such that resampling is avoided if the sample rate of the source data is supported by the device ie. use exclusive mode and set the device sample rate to that of the source data (this is for people who expect bit-perfect output). While I expect most music files will be 44100, some might have different sample rates. From what I can see the only way to play different sample rates (without resampling) is to free and re-initialise the device. Is that something you would advise against doing for any reason?

No, that should be fine. As you say, it is necessary if you want to avoid resampling while using different sample rates. One issue is that it prevents gapless output, ie. there will be a small break in the sound as the device is reinitialized.

[Mike Wittman]

Hi IAN;

Related to the two previous posts I was wondering about the purpose of Lock.

If in WASAPI Exclusive mode, using "bit-perfect" rendering; if all I'm doing is using BASS to Decode and WASAPI to render the audio, with NO mixer involved; can I use GetData for visualizations without the need for the "Lock" ?

Your thoughts are much obliged !

Mike Wittman

[ken]

Where are you calling that code from? I guess a timer in the main thread? Are you also using any callback functions (eg. DSPPROC/SYNCPROC), and if so, what are they doing, eg. any GUI stuff?

Yes i'ts a timer pulling my GetPosition. I do use SyncProc for geting "mix" position and end of stream. I don't think its a thread issue, C# errormessage normaly say when I crossthread. This is the error I get when code get to "lock" I also tried to remove all my BASS_Mixer_ChannelSetSync, same thing.

Cannot marshal 'return value': Invalid managed/unmanaged type combination (Single must be paired with R4).

[radio42]

The error message indicates, that you are using/invoking a method which expects a 'float' return value.
But neither the "BASS_Mixer_ChannelGetPositionEx" nor the "BASS_WASAPI_Lock" return a float value - at least not as stated in the BASS_WASAPI docs/API.

So can you confirm which BASS_WASAPI call creates this error message?!

So I can only imagine two scenarios for the error message:
a) BASS_WASAPI indeed returns a float value - but the API is simply incorrect
b) the error message is actually thrown by another function call

[Ian @ un4seen]

Related to the two previous posts I was wondering about the purpose of Lock.

If in WASAPI Exclusive mode, using "bit-perfect" rendering; if all I'm doing is using BASS to Decode and WASAPI to render the audio, with NO mixer involved; can I use GetData for visualizations without the need for the "Lock" ?

Yep, there is no need to lock in that case. It would only be used with the code above to ensure that the "_delay" value doesn't get invalidated before it is used in the BASS_Mixer_ChannelGetPositionEx call.

Yes i'ts a timer pulling my GetPosition. I do use SyncProc for geting "mix" position and end of stream. I don't think its a thread issue, C# errormessage normaly say when I crossthread. This is the error I get when code get to "lock" I also tried to remove all my BASS_Mixer_ChannelSetSync, same thing.

Cannot marshal 'return value': Invalid managed/unmanaged type combination (Single must be paired with R4).

Just to be clear, is the BASS_ChannelLock call hanging or is it generating an error?

[ken]

Just to be clear, is the BASS_ChannelLock call hanging or is it generating an error?

When the code comes to BASS_ChannelLock , it "hangs" and I get this message in debug (C# with Bass.Net)

Cannot marshal 'return value': Invalid managed/unmanaged type combination (Single must be paired with R4).

[radio42]

This is even more puzzling, as BASS_ChannelLock also doesn't use any float parameters/return values.
Are you may be calling BASS_ChannelLock from within a DSPPROC?

[fmcoder]

Wasapi works fine. The strange thing I noticed. If I use only WASAPI, with buffer set to "0.05" seconds, the playback latency is that 0.05 seconds. If I also use another output with DirectSound card, and there is 2 seconds buffer - the latency in WASAPI output also becomes 2 seconds. Why is that?
Both of those outputs share the same source (two splitter channels are made for 2 outputs).

UPD I noticed that if I remove the splitter creation for DS card, the latency is not increased, i.e. it stays at 0.05 seconds. That means, the splitter for Directsound card does something which affects the Wasapi output.

[Ian @ un4seen]

To allow the splitter streams to receive all of the source data, they share a buffer. If the DirectSound output is requesting 2 seconds of data in advance and the WASAPI output is requesting only 0.05 seconds, then the splitter will have to keep 1.95 seconds of data buffered for the WASAPI output so that it doesn't miss any.

What issues is the latency causing? If it's delaying DSP/FX changes, you could apply those to the splitters rather than the source.

[fmcoder]

The issues are: when user turns on'off microphone, there is a delay, or when changing track pos, and many others like this. I think I just should advice users not to use DirectSound to get rid of this latency.

[Ian @ un4seen]

Couldn't you just lower the buffer (BASS_CONFIG_BUFFER) setting? If 50ms is working well with WASAPI output, then you can probably use something similar with DirectSound too, ie. 2 seconds is probably excessively conservative.

[Mike Wittman]

Ian;

I was wondering if you could expose the IMMDeviceEnumerator::RegisterEndpointNotificationCallback through the WASAPI driver.

This would be helpful on a lot of points:

1) Respond to a "Default Device" change
1) A soundcard (like USB sound) is plugged in or out; so I could reorder the DeviceID's automatically.
2) For access to the "new" jack sence capabilities of Vista/7

I could do this this by writing "C" code but I prefer to do it in Delphi which poses some complexities w/ COM and Property Stores.

Any thoughts on this ?

Mike W.

[Ian @ un4seen]

That may be possible to add. The current BASS release (2.4.6) actually already includes it via a currently undocumented CONFIG option, but it is a bit troublesome, so it may be removed in the next release. The trouble is, as you mention, it is COM-based, which makes it awkward to release gracefully (COM stuff can't be accessed in the DLL's DllMain function). BASSWASAPI would have the same issue, so it would probably have to be up to the user to uninitialize it before closing the app. I'll look into it.

[Mike Wittman]

I appreciate you having a look-see;

I hate asking questions that appear to "trivialize" the effort involved.  My thinking was that you already had the IMMDeviceEnumerator "hanging around" and could just expose the interface .. similar to the BASS_Init function with the Directsound CLSID "hook".

Was unaware of the BASS_SetConfig option, but that would be interesting as well.

[Ian @ un4seen]

There is now an update in the BASSWASAPI package, which adds a BASS_WASAPI_SetNotify function to set a callback function to receive notification of device changes. It hasn't been tested much yet, so please report how you get on with it.

[stevenmmm]

When using BASS_WASAPI_SetVolume (linear=true) it updates the volume of the control panel but it doesnt seem to scale the same way eg. set volume to 0.03 and the result on the control panel is 10% and it goes higher on the control panel faster than the linear scale value set using the API. I also tried using linear=false but of course i wasnt supplying the db value so it stuck at 100%.
In the end I didnt want the control panel to be updated anyway, so I've used a different approach.

Also one other thing - you mention not to call BASS_WASAPI_Free in callback functions. So in a SYNCPROC what i do it create a new thread which calls BASS_WASAPI_Free. That seems to work OK but could you confirm thats a safe approach?

[Ian @ un4seen]

When using BASS_WASAPI_SetVolume (linear=true) it updates the volume of the control panel but it doesnt seem to scale the same way eg. set volume to 0.03 and the result on the control panel is 10% and it goes higher on the control panel faster than the linear scale value set using the API. I also tried using linear=false but of course i wasnt supplying the db value so it stuck at 100%.
In the end I didnt want the control panel to be updated anyway, so I've used a different approach.

Windows Vista/7 volume sliders don't use either a linear or logarithmic volume curve, but rather some hybrid, so they won't match BASS_WASAPI_Set/GetVolume in either linear or logarithmic mode.

   http://msdn.microsoft.com/en-us/library/dd370798.aspx

Also one other thing - you mention not to call BASS_WASAPI_Free in callback functions. So in a SYNCPROC what i do it create a new thread which calls BASS_WASAPI_Free. That seems to work OK but could you confirm thats a safe approach?

Yes, that should be absolutely fine.

[Mike Wittman]

The BASS_WASAPI_SetNotify is great; Thanks IAN;

Can you answer this "general operation" question?  I'm trying to find a "graceful" way of recovering from the add/remove device issue.

In the event that a new sound device is added or removed; does WASAPI behave like BASS, in that the Device ID's for all devices change?

It seems that in Vista, if a USB device is plugged in, then it's automatically made the "default", which tells me to rescan the list for new ID's.  But this does NOT seem to be true in Windows 7.  Which means that I can't tell if a new device is added in Windows 7.


Mike Wittman

[Ian @ un4seen]

In the event that a new sound device is added or removed; does WASAPI behave like BASS, in that the Device ID's for all devices change?

BASS doesn't change the device IDs, but that can be the end result if Windows rearranges the devices. I don't think that should happen on Vista/7, with either BASS/DirectSound or WASAPI, as they have a different way of identifying the devices (not sequential numbers). Let me know if you find that it does happen though.

It seems that in Vista, if a USB device is plugged in, then it's automatically made the "default", which tells me to rescan the list for new ID's.  But this does NOT seem to be true in Windows 7.  Which means that I can't tell if a new device is added in Windows 7.

A BASS_WASAPI_NOTIFY_CHANGE notification should be received when a new device is added. Are you not receiving one? Assuming you do receive a notification, you could detect whether it is a new device by retaining the last known device count and comparing the notification's device number with that.