Author Topic: BASSWASAPI beta  (Read 139955 times)

Mike Wittman

  • Posts: 20
Re: BASSWASAPI beta
« Reply #25 on: 10 May '10 - 15:21 »
Thanks Ian;

Yes; it's ALL about the "bit resolution"!  I don't know if you follow "Audiophile" digital music threads; but in essence the guys that spend $20,00 on speakers  (I'm not in that league, by the way); don't want thier PC messing with the audio stream.  It's about RFI/EMI, jitter, signal compression or modification, you name it they hate it!

So I've developed an USB Isochronous/Asynchronous w/ rate feedback (DACless) soundcard and a "music librarian" for my Audiophile friends to keep the audio signal jitter-free and "pure" digital throughout the signal path.

In the Audiophile world of lossless digital music then; upsampling the bit resolution is ok, but frequency shifts are very controversial.  After a lot of hardware research; I found the recommendation to upsample frequency only in 2X increments; ie., 44.1 to 88.2 etc.  Yet, there is also a strong belief that modern PC's running DSP algorithmns can do this more effectively than hardware.  So at some point soon I'll be interested in your BASSmix product.

But for now; I'm just focusing on WASAPI in exclusive mode and doing exact frequency matches which will allow "upsampling" of the sample bit resolution.

PS: If I get this right, I'm sure there's "commercial potential" and then I can pay you the licensing fees you so richly deserve!

Ian @ un4seen

  • Administrator
  • Posts: 19285
Re: BASSWASAPI beta
« Reply #26 on: 11 May '10 - 14:34 »
OK. It looks like one small change that could simplify/speed things for you would be to have BASS_WASAPI_CheckFormat return the supported resolution (BASS_WASAPI_FORMAT_xxx) rather than simply TRUE. Do you just want to be able to detect the (maximum) resolution, not set it? As you say, using a higher resolution than necessary (eg. 24-bit output for 16-bit data) won't break lossless output.

Btw, have you received the debug DLL version? It appears to have been delivered, so if you don't see it, please check your spam folder.

Mike Wittman

  • Posts: 20
Re: BASSWASAPI beta
« Reply #27 on: 11 May '10 - 16:53 »
That would be great IAN  !

Using BASS_WASAPI_CheckFormat to get the "highest bit resolution" would be much less overhead !

What might be even more thorough; is being able to get the "exact" match, perhaps with an (ExactMatch) boolean prameter defaulted to false.  Where True says I need the exact resolution and False (default) returns the "highest" available.

PS: I've just sent you my debug results

Mike Wittman

  • Posts: 20
Re: BASSWASAPI beta
« Reply #28 on: 11 May '10 - 18:47 »
Ian - I just reread your post and I missed the question in there ..

No - I do not need to "set" the bit resolution as long as BASS_WASAPI is using the highest available.  I just need to know what it is, so that I can display the difference (especially in case where it might be "down-sampled").

[STANDING on my SOAPBOX ..]

From an "audiophile purist" point of view; IF.. the BASS.dll decoder could be coerced into producing 24 bit samples (I know the DirectSound/Render side can't handle this), then there is an argument to stay in the "integer" world and hence, explicitly set "exact" bit resolutions on the device. 

This is for two reasons.  One; is that the compiler/cpu accuracy of converting an integer into a range of +1.0 to -1.0 (32bit fp) isn't truly exact and two; to eliminate the overhead of 2 conversions (back and forth), and just pump the output to WASAPI.

But overall your design decision to use 32bit float makes alot of sense; especially since quite a few CODEC's use it natively.  In fact; one obvious benefit of 32bit FP (that I can actually "hear") is enhanced Volume and Parametric EQ FX (or any DSP).

Unfortunately in the "lossless" rendering world; non-floating point formats (like FLAC, WAV and Apple Lossless) arguably "suffer" from it.

But life is about making "right" compromies, no?

Mike Wittman.

Mike Wittman

  • Posts: 20
Re: BASSWASAPI beta
« Reply #29 on: 12 May '10 - 16:41 »
Ian;

In regards to my previous post, perhaps there's an alternative and "cleaner" solution ..

Since 95% of all music is recorded in the "redbook" format (i.e. 44100 Hhz, 16 bit, 2 Channel).  What if; you added and overloaded version of the WASAPIPROC callback function where the buffer points to integer data? 

This way, we could use the normal BASS decoder functions and pump "bit perfect" data thru WASAPI exclusive mode!

It also might open a "back door" to other integer formats such as 24 bit (getting more common) and 32 bit (studio recordings).

Just thinking out loud ..

Ian @ un4seen

  • Administrator
  • Posts: 19285
Re: BASSWASAPI beta
« Reply #30 on: 13 May '10 - 16:53 »
Using BASS_WASAPI_CheckFormat to get the "highest bit resolution" would be much less overhead !

An update is in the BASSWASAPI package (see 1st post), in which the BASS_WASAPI_CheckFormat return value has been changed to a BASS_WASAPI_FORMAT value to indicate the maximum supported resolution. A new error code (BASS_ERROR_BUSY) has also been added for BASS_WASAPI_Init, to indicate that the device is busy, eg. in "exclusive" use by another process.

What might be even more thorough; is being able to get the "exact" match, perhaps with an (ExactMatch) boolean prameter defaulted to false.  Where True says I need the exact resolution and False (default) returns the "highest" available.

Do you mean checking the support for specific resolutions? So long as BASS always uses the highest available resolution (as is currently the case), I'm not sure there is really any need for that.

This is for two reasons.  One; is that the compiler/cpu accuracy of converting an integer into a range of +1.0 to -1.0 (32bit fp) isn't truly exact and two; to eliminate the overhead of 2 conversions (back and forth), and just pump the output to WASAPI.

32-bit floating-point can bit-perfectly maintain up to 24-bit integer data, so nothing will be lost in that conversion. If the source data isn't originally floating-point, it does mean some CPU overhead, but that is low. Note the lossy format decoders (eg. MP3/OGG/MPC/AAC) will generally produce floating-point data internally, so it is actually less overhead to keep them floating-point; I say "generally" as the Windows MP3 codec is an exception, as is WMA.

There are a few reasons for BASSWASAPI always using floating-point sample data, but primarilly it is to keep things simple; the user only has to use the BASS_SAMPLE_FLOAT flag when creating source streams regardless of the file format, and BASSWASAPI doesn't have to bother with converting between different integer resolutions (eg. if the user wants to play 24-bit data but the device only supports 16-bit). Another consideration is that BASS doesn't currently include 24-bit stream support, so the only way to play 24-bit files bit-perfectly is to use a floating-point stream anyway :)

Mike Wittman

  • Posts: 20
Re: BASSWASAPI beta
« Reply #31 on: 13 May '10 - 22:28 »
Thanks for the update Ian;

The suggestion for an "ExactMatch" parameter in BASS_WASAPI_CheckFormat was to query the device to 1) get its absolute current setting (say retrieve the Windows default setting) and 2) build a list of all supported formats.  Purely "dashboard" stuff NOT a core function.

The changes you made to BASS_WASAPI_CheckFormat solved my problem with having to INIT to test every frequency/bit resolution combination - GREAT!

As you know I've already found use for the new BASS_ERROR_BUSY code !

As for 32 bit float vs 24 bit integers, I agree that arithemetically they can be proven equivalent.  But my years in the scientific and financial programming jungle has taught me that this is less true in the "wild".  Fractions with repeating patterns will be rounded or truncated after about the 8 significant digit and hence multiplying the result to get the original number back can be proven to be problematical  ( ??? what is effortless on a $2 calculator causes a microprocesser fits) Of course the margin of error is ridiculously low and doesn't have alot of significance here.

If however; I use the legal term "bit perfect" in marketing materials you can bet a $1000 that some Audiophile will plugin a digital loopback connection and compare the output sample by sample ! (and then want his money back)  ::)

I'm fine with 32bit FP as you've implemented it.

Ian @ un4seen

  • Administrator
  • Posts: 19285
Re: BASSWASAPI beta
« Reply #32 on: 14 May '10 - 17:45 »
As for 32 bit float vs 24 bit integers, I agree that arithemetically they can be proven equivalent.  But my years in the scientific and financial programming jungle has taught me that this is less true in the "wild".  Fractions with repeating patterns will be rounded or truncated after about the 8 significant digit and hence multiplying the result to get the original number back can be proven to be problematical  ( ??? what is effortless on a $2 calculator causes a microprocesser fits) Of course the margin of error is ridiculously low and doesn't have alot of significance here.

That could be a problem if additional operations are performed on the data mid-sequence, but not so if it is just an integer->float->integer conversion sequence, unless there is something very wrong with the FPU :)

An explanation and additional information on the subject can be found here:

   http://en.wikipedia.org/wiki/Floating_point

Quote
Any integer with absolute value less than or equal to 224 can be exactly represented in the single precision format, and any integer with absolute value less than or equal to 253 can be exactly represented in the double precision format. Furthermore, a wide range of powers of 2 times such a number can be represented.

Mike Wittman

  • Posts: 20
DX Effects, DSP and BASSWASAPI
« Reply #33 on: 15 May '10 - 17:13 »
Do the DirectSound FX still work under WASAPI ? (I'm not opening a stream using the BASS_SAMPLE_FX flag)

How about DSP?

In other words; since we're opening streams as a decode, pretty much everthing you can do in decode should work in WASAPI, right?

I've never done a BASS_Init with a "no sound" device before, so I was wondering what signal processing  (if any) can be applied before "sample data" is sent to WASAPI via the "callback".

Ian @ un4seen

  • Administrator
  • Posts: 19285
Re: BASSWASAPI beta
« Reply #34 on: 17 May '10 - 16:23 »
Yes, DSP/FX can be applied when using WASAPI output. An example of that can be found in the SYNTH example included in the BASSWASAPI package. DSP/FX can also be applied to any sample data via a "dummy" stream (with the same format as the data), something like this...

Code: [Select]
dummy = BASS_StreamCreate(freq, chans, BAS_SAMPLE_FLOAT|BASS_STREAM_DECODE, STREAMPROC_DUMMY, NULL); // create a dummy stream
BASS_ChannelSetFX(dummy, ...); // set some FX on it

...

BASS_ChannelGetData(dummy, data, datalen); // pass some sample data through the dummy stream

The reason that works is that dummy streams don't have any sample data of their own, so the BASS_ChannelGetData buffer content remains and gets passed through any DSP/FX that are on the dummy stream.

Mike Wittman

  • Posts: 20
Re: BASSWASAPI beta
« Reply #35 on: 17 May '10 - 17:07 »
That's fantastic (FX/DSP) news .. a very comprehensive WASAPI solution  :D

Regarding the use of the BASS mixer (for either WASAPI Shared OR Exclusive) .. I was wondering a bit about the "mixer" internals; since I've not used it before.

Is the mixer a wrapper around DirectSound or a custom implementation that you've developed yourself?  From my perspective, using the mixer to "upsample" WASAPI  (ex. 44.1 KHz to 88.2) could be very powerful (especially with DSP) .  How would you assess the BASS Mixer implementation in regards to such tasks?

Any downsides from your experience?

 

Ian @ un4seen

  • Administrator
  • Posts: 19285
Re: BASSWASAPI beta
« Reply #36 on: 18 May '10 - 15:50 »
BASSmix uses its own mixing and resampling routines. It isn't the pinnacle of resampling, but it's not the worst either :) ... The BASS_MIXER_FILTER flag can be used (with BASS_Mixer_StreamAddChannel) to reduce aliasing; also see the BASS_CONFIG_MIXER_FILTER config option.

ifynk

  • Posts: 3
Re: BASSWASAPI beta
« Reply #37 on: 19 May '10 - 08:56 »
Why when i use SFX the playing of song be faster?

And BASS_ChannelIsActive(FAudioStream) always return BASS_ACTIVE_PLAYING. How i can Play and Pause my Stream?

PS: Sorry for my poor english.
« Last Edit: 19 May '10 - 10:00 by ifynk »

Ian @ un4seen

  • Administrator
  • Posts: 19285
Re: BASSWASAPI beta
« Reply #38 on: 19 May '10 - 15:51 »
Why when i use SFX the playing of song be faster?

The problem there will be that the vis processing is taking data from the decoding channel (via BASS_ChannelGetData), and that data is then missing from the BASS_ChannelGetData call in your WASAPIPROC.

And BASS_ChannelIsActive(FAudioStream) always return BASS_ACTIVE_PLAYING. How i can Play and Pause my Stream?

You can use BASS_WASAPI_Stop (reset=FALSE) to pause the output, and then BASS_WASAPI_Start to resume it.

Note that with a decoding channel (BASS_STREAM_DECODE used at creation), BASS_ChannelIsActive indicates whether it has reached the end... BASS_ACTIVE_STOPPED = ended, BASS_ACTIVE_PLAYING = not.

fmcoder

  • Posts: 423
Re: BASSWASAPI beta
« Reply #39 on: 19 May '10 - 18:13 »
Hello!
Just started to work with this addon. Seems to work fine, thanks.
It it possible to do speaker assignment when using WASAPI output?

fmcoder

  • Posts: 423
Re: BASSWASAPI beta
« Reply #40 on: 19 May '10 - 18:21 »
just found the Speakers example, everything is there :) Sorry for bothering.

Ian @ un4seen

  • Administrator
  • Posts: 19285
Re: BASSWASAPI beta
« Reply #41 on: 20 May '10 - 16:18 »
Why when i use SFX the playing of song be faster?

The problem there will be that the vis processing is taking data from the decoding channel (via BASS_ChannelGetData), and that data is then missing from the BASS_ChannelGetData call in your WASAPIPROC.

Regarding a solution, you could create a custom stream to use with BASS_SFX, which you would feed with data from BASSWASAPI. It could look something like this...

Code: [Select]
BASS_WASAPI_INFO wi;
BASS_WASAPI_GetInfo(&wi); // get WASAPI info
sfxstream=BASS_StreamCreate(wi.freq, wi.chans, BASS_SAMPLE_FLOAT|BASS_STREAM_DECODE, StreamProc, NULL); // create custom stream with same format

...

DWORD CALLBACK StreamProc(HSTREAM handle, void *buf, DWORD len, void *user)
{
DWORD c=BASS_WASAPI_GetData(buf, len); // get data from the WASAPI output
if (c==-1) c=0; // an error
    return c;
}

You would use the "sfxstream" handle in the BASS_SFX calls. You also need to use the BASS_WASAPI_BUFFER flag in your BASS_WASAPI_Init call to enable the BASS_WASAPI_GetData function.

fmcoder

  • Posts: 423
Re: BASSWASAPI beta
« Reply #42 on: 20 May '10 - 20:30 »
Strange behaviour of WASAPI addon.
If I use the "-1" device number, everything works great. But if I use specific device number, like "2", all calls to BASS_WASAPI_* functions are successful, but there is no sound.
I checked, it makes calls to the WasapiProc.
What could it be?

Also, how can I control the output volume without using the BASS_WASAPI_SetVolume function (as it changes the global device volume in the system)? Write my own dsp?

Thanks.
« Last Edit: 20 May '10 - 20:43 by fmcoder »

Ian @ un4seen

  • Administrator
  • Posts: 19285
Re: BASSWASAPI beta
« Reply #43 on: 21 May '10 - 14:10 »
Strange behaviour of WASAPI addon.
If I use the "-1" device number, everything works great. But if I use specific device number, like "2", all calls to BASS_WASAPI_* functions are successful, but there is no sound.
I checked, it makes calls to the WasapiProc.
What could it be?

Is device 2 an output device? Note that the device list contains both output and input devices, so you need to use BASS_WASAPI_GetDeviceInfo to find out which are which; you can find a demonstration of that in the RECTEST example.

Also, how can I control the output volume without using the BASS_WASAPI_SetVolume function (as it changes the global device volume in the system)? Write my own dsp?

Yes, you could write your own DSP to do that, or use BASS_FX's BASS_FX_BFX_VOLUME effect. If you're using BASSmix, another option is to make use of the sources' BASS_ATTRIB_VOL attribute (via BASS_ChannelSetAttribute).

fmcoder

  • Posts: 423
Re: BASSWASAPI beta
« Reply #44 on: 21 May '10 - 14:30 »
Is device 2 an output device? Note that the device list contains both output and input devices, so you need to use BASS_WASAPI_GetDeviceInfo to find out which are which; you can find a demonstration of that in the RECTEST example.
I will check this. Maybe, this is a problem. Thanks.

Yes, you could write your own DSP to do that, or use BASS_FX's BASS_FX_BFX_VOLUME effect. If you're using BASSmix, another option is to make use of the sources' BASS_ATTRIB_VOL attribute (via BASS_ChannelSetAttribute).
I'm using Splitter, i.e one Mixer channel splitted to many outputs. But it seems, that splitter doesn't takes source (which is mixer channel) volume into account. I'll try to play with DSP.

aybe

  • Posts: 143
Re: BASSWASAPI beta
« Reply #45 on: 26 May '10 - 14:08 »
Hello,

I am getting the following error when using the library :

An incorrect version of BASSWASAPI was loaded !

Version loaded : 0.0
Version expected : 1.0


Any further calls produce weird results like 150 devices present ...

I have updated my Bass.Net reference with the DLL on the first post but it didn't help much ...

Thank you !

radio42

  • Posts: 4446
Re: BASSWASAPI beta
« Reply #46 on: 26 May '10 - 16:42 »
Please try this version (as it includes the latest WASAPI updates):

Pre v2.4.6.5:
  www.un4seen.com/filez/4/Bass24.Net_pre.zip

aybe

  • Posts: 143
Re: BASSWASAPI beta
« Reply #47 on: 26 May '10 - 18:34 »
I've just tested the link you gave me,

It's almost ok (no more version error) BUT results are still completely wrong,
I am still getting +150 devices detected with BASS_WASAPI_GetDeviceInfos()  ???

Any ideas ?

Thank you  :D

ken

  • Posts: 730
Re: BASSWASAPI beta
« Reply #48 on: 26 May '10 - 22:12 »
I've just tested the link you gave me,

It's almost ok (no more version error) BUT results are still completely wrong,
I am still getting +150 devices detected with BASS_WASAPI_GetDeviceInfos()  ???

Any ideas ?

Thank you  :D

aybe, try my code snipp for listing devices. I found that wasapi is very different to directx and asio:  http://www.un4seen.com/forum/?topic=11170.msg78373#msg78373

aybe

  • Posts: 143
Re: BASSWASAPI beta
« Reply #49 on: 27 May '10 - 15:03 »
Alright thanks  ;D