• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required as is 20 years of participation in forums (not all true). Come here to have fun, be ready to be teased and not take online life too seriously. We now measure and review equipment for free! Click here for details.

Kernel Streaming, ASIO, WASAPI... and music players (Foobar, JRiver...)

SIY

Major Contributor
Technical Expert
Joined
Apr 6, 2018
Messages
6,032
Likes
12,754
Location
Phoenix, AZ
Others insist. For two times I have asked for a new thread and that I would participate in it. No need to discuss more about it here. Now it is the third.
Start your own thread. There's a button and everything for it. It will make ignoring this stuff easier for everyone, so don't be surprised if no-one else participates.

screen shot- forum.png
 

maty

Major Contributor
Joined
Dec 12, 2017
Messages
3,893
Likes
2,475
Location
Tarragona (Spain)
Why can not I say that one software player sounds better than another on my systems? Is it something so serious? Others are always looking to go further.
 

edechamps

Addicted to Fun and Learning
Forum Donor
Joined
Nov 21, 2018
Messages
714
Likes
2,866
Location
London, United Kingdom
Why can not I say that one software player sounds better than another
Because that's an extraordinary claim, and extraordinary claims with no evidence are just noise.
 
Last edited:

Blumlein 88

Major Contributor
Forum Donor
Joined
Feb 23, 2016
Messages
11,654
Likes
17,255
Why can not I say that one software player sounds better than another on my systems? Is it something so serious? Others are always looking to go further.
Why can not I say that one software player sounds better than another on my systems? Is it something so serious? Others are always looking to go further.
https://www.audiosciencereview.com/...sound-different-from-each-other-and-why.8269/

I started a thread for you. Give us a good reply on how you determined software players sound different.
 
OP
daftcombo

daftcombo

Major Contributor
Forum Donor
Joined
Feb 5, 2019
Messages
3,088
Likes
3,046
Thread Starter #247
Anybody played with the "hardware buffer" for WASAPI 1.3.3 in Foobar?
Default is 200ms in Push mode and 25ms in Event mode.
Why and can we expect a difference between both modes and hardware buffer values?
 

majingotan

Addicted to Fun and Learning
Forum Donor
Joined
Feb 13, 2018
Messages
925
Likes
952
Location
Laguna, Philippines
Anybody played with the "hardware buffer" for WASAPI 1.3.3 in Foobar?
Default is 200ms in Push mode and 25ms in Event mode.
Why and can we expect a difference between both modes and hardware buffer values?
I set mine to 5010ms to prevent any dropouts. There is absolutely zero difference whatsoever in sound quality between the 25ms default and 5010ms

Capture.PNG
 
OP
daftcombo

daftcombo

Major Contributor
Forum Donor
Joined
Feb 5, 2019
Messages
3,088
Likes
3,046
Thread Starter #249
I set mine to 5010ms to prevent any dropouts. There is absolutely zero difference whatsoever in sound quality between the 25ms default and 5010ms

View attachment 32456
Thanks but I was talking about the hardware buffer settings in Properties/Advanced/Playback/WASAPI.

About the buffer length you indicate, I set it to 2000ms.
 
OP
daftcombo

daftcombo

Major Contributor
Forum Donor
Joined
Feb 5, 2019
Messages
3,088
Likes
3,046
Thread Starter #250
Other question: is there any need to give "real-time priority" or "high priority" to Foobar2000?
 

majingotan

Addicted to Fun and Learning
Forum Donor
Joined
Feb 13, 2018
Messages
925
Likes
952
Location
Laguna, Philippines
It's the first time I've seen that setting BTW. Yeah, I've never played with that part though but the high worker process priority is checked by default on mine
 

zermak

Senior Member
Joined
Jun 2, 2019
Messages
337
Likes
225
Location
Italy
Anybody played with the "hardware buffer" for WASAPI 1.3.3 in Foobar?
Default is 200ms in Push mode and 25ms in Event mode.
Why and can we expect a difference between both modes and hardware buffer values?
To prevent any problem in Event mode I use it at 100ms (same as in Push mode which never caused issues with that setting).
 

majingotan

Addicted to Fun and Learning
Forum Donor
Joined
Feb 13, 2018
Messages
925
Likes
952
Location
Laguna, Philippines
Main reason why I hate iTunes on Windows even if it does support WASAPI Exclusive as you can see that it skips the mixer when playing back music

Untitled.png
 

Sal1950

Major Contributor
The Chicago Crusher
Forum Donor
Joined
Mar 1, 2016
Messages
8,709
Likes
8,076
Location
Central Fl
Friends don't let friends use Windoz. :p
 

weesch

New Member
Joined
Apr 28, 2021
Messages
3
Likes
0
ASIO, WASAPI Exclusive, and WDM-KS are all bit-perfect as far as a typical software stack is concerned, so there shouldn't be any difference between them.

MME, DirectSound and WASAPI Shared do not provide bit-perfect guarantees. However, if the sample rate matches the one configured in the Windows audio control panel, and assuming you don't have any APOs ("audio effects") enabled, the worst that can happen is an extra layer of dithering, which is benign. If the sample rate doesn't match, then you're at the mercy of the Windows sample rate converter. I'm not sure how good Windows SRC is; maybe some day I'll do some measurements to investigate. However, it's quite unlikely you'll hear a significant difference even with a crappy SRC.



Unsurprising. You're highly unlikely to hear any difference between audio output methods. That's not what matters.



There are a few inaccuracies in the statement you quoted. (My credentials: I wrote two ASIO drivers, including FlexASIO which is basically a bridge between ASIO and other output methods. As part of that work I investigated the various Windows audio APIs quite extensively.)



This is wrong. WASAPI Exclusive also (typically) gives you direct access to the hardware audio buffers. The difference between WDM-KS and WASAPI is that the former has a lower-level interface for enumerating and configuring devices. But when it comes to the audio buffers themselves, both should provide direct access to hardware memory (if applicable).



I'm not sure what this statement is supposed to mean. ASIO, WASAPI and WDM-KS can all provide direct access to hardware memory buffers, which is typically what is meant by "zero-copy" operation. Maybe WDM-KS has a way of telling the audio driver to get the data directly from a user-space buffer, which would indeed remove one copy operation, but that would be the first I hear of it. Also, I don't see the point of discussing copies: copying data can affect performance (although not significantly), but it can't affect audio quality, since it's bit-perfect.



That's an extraordinary claim, and it would take extraordinary evidence for me to believe it.



That statement is false; ASIO absolutely allows the user to customize the buffer size very easily. It's right there in the core ASIO API that all ASIO drivers have to support. Maybe some ASIO drivers only allow one buffer size, but then that's a limitation of that specific driver, not a limitation of ASIO in general.



True. But again, I don't see the point of discussing copies.



No matter what output method you use, a buffer size of only one sample will never work on a general-purpose OS such as Windows, which doesn't have the necessary real-time scheduling capabilities to make that work. It's also quite pointless. What the author might be referring to is single-sample granularity (i.e. the application knows the cursor position with a precision of one sample), which I guess is pretty cool, and might be useful for achieving very low latency or precise synchronization between multiple clocks, but again I don't see how that's related to audio quality. (I'm also quite sceptical of the claim that KS can offer single-sample granularity on typical hardware.)

My personal opinion: if I had to choose between bit-perfect output methods, I would choose WASAPI Exclusive because that's the modern API that Microsoft actively supports and that audio devices are tested with nowadays. It's also a simpler API than WDM-KS, which means applications using it are less likely to have bugs where they're using the API incorrectly. ASIO is also a good choice if there is a native driver provided by the audio device manufacturer.
ASIO, WASAPI Exclusive, and WDM-KS are all bit-perfect as far as a typical software stack is concerned, so there shouldn't be any difference between them.

MME, DirectSound and WASAPI Shared do not provide bit-perfect guarantees. However, if the sample rate matches the one configured in the Windows audio control panel, and assuming you don't have any APOs ("audio effects") enabled, the worst that can happen is an extra layer of dithering, which is benign. If the sample rate doesn't match, then you're at the mercy of the Windows sample rate converter. I'm not sure how good Windows SRC is; maybe some day I'll do some measurements to investigate. However, it's quite unlikely you'll hear a significant difference even with a crappy SRC.



Unsurprising. You're highly unlikely to hear any difference between audio output methods. That's not what matters.



There are a few inaccuracies in the statement you quoted. (My credentials: I wrote two ASIO drivers, including FlexASIO which is basically a bridge between ASIO and other output methods. As part of that work I investigated the various Windows audio APIs quite extensively.)



This is wrong. WASAPI Exclusive also (typically) gives you direct access to the hardware audio buffers. The difference between WDM-KS and WASAPI is that the former has a lower-level interface for enumerating and configuring devices. But when it comes to the audio buffers themselves, both should provide direct access to hardware memory (if applicable).



I'm not sure what this statement is supposed to mean. ASIO, WASAPI and WDM-KS can all provide direct access to hardware memory buffers, which is typically what is meant by "zero-copy" operation. Maybe WDM-KS has a way of telling the audio driver to get the data directly from a user-space buffer, which would indeed remove one copy operation, but that would be the first I hear of it. Also, I don't see the point of discussing copies: copying data can affect performance (although not significantly), but it can't affect audio quality, since it's bit-perfect.



That's an extraordinary claim, and it would take extraordinary evidence for me to believe it.



That statement is false; ASIO absolutely allows the user to customize the buffer size very easily. It's right there in the core ASIO API that all ASIO drivers have to support. Maybe some ASIO drivers only allow one buffer size, but then that's a limitation of that specific driver, not a limitation of ASIO in general.



True. But again, I don't see the point of discussing copies.



No matter what output method you use, a buffer size of only one sample will never work on a general-purpose OS such as Windows, which doesn't have the necessary real-time scheduling capabilities to make that work. It's also quite pointless. What the author might be referring to is single-sample granularity (i.e. the application knows the cursor position with a precision of one sample), which I guess is pretty cool, and might be useful for achieving very low latency or precise synchronization between multiple clocks, but again I don't see how that's related to audio quality. (I'm also quite sceptical of the claim that KS can offer single-sample granularity on typical hardware.)

My personal opinion: if I had to choose between bit-perfect output methods, I would choose WASAPI Exclusive because that's the modern API that Microsoft actively supports and that audio devices are tested with nowadays. It's also a simpler API than WDM-KS, which means applications using it are less likely to have bugs where they're using the API incorrectly. ASIO is also a good choice if there is a native driver provided by the audio device manufacturer.
hello man !
i think you are the one who understand what happens by using computer asio with the problems of latency...
in the begening a use tape recorder (tascam porta 05) and since i work with computer i never found how to have the same groove that i have with porta 05...
i use protools hd and samplitude with creamware scope 5.0 that i have modify to work with windows 7 x64....
i 'am near the point of 0 latency by using samplitude with asio scope and protools hd 10 at the same time and in the same computer.....
samplitude feed midi to protools and samplitude record what's going out from tdm or rtas plugins of protools hd...
i mixing all with a yamaha 01v96 at 44 khz.....
rtas plugins guitar rig do 168 samples of latency.... yamaha 01v96 64 samples of latency and asio scope do also 64 sample of latency so i put 300 sample in the recording offset of samplitude to compensate latency of protools / scope / and 01v96....
the result is near the 0 point but i hear something wrong....
i have synchronise time code between samplitude ans protools...
i 'am so near the real time plugin recording system...
have you an idae to optimise my system
is there a realtime dsp asio sytem ? ( by analog device)
thanks for your reply phil weesch
i let a demos song of my system enjoy !
 

AdamG247

MQA Fight Club Mgr. 1st rule of MQA fight club….
Moderator
Forum Donor
Joined
Jan 3, 2021
Messages
1,110
Likes
1,634
hello man !
i think you are the one who understand what happens by using computer asio with the problems of latency...
in the begening a use tape recorder (tascam porta 05) and since i work with computer i never found how to have the same groove that i have with porta 05...
i use protools hd and samplitude with creamware scope 5.0 that i have modify to work with windows 7 x64....
i 'am near the point of 0 latency by using samplitude with asio scope and protools hd 10 at the same time and in the same computer.....
samplitude feed midi to protools and samplitude record what's going out from tdm or rtas plugins of protools hd...
i mixing all with a yamaha 01v96 at 44 khz.....
rtas plugins guitar rig do 168 samples of latency.... yamaha 01v96 64 samples of latency and asio scope do also 64 sample of latency so i put 300 sample in the recording offset of samplitude to compensate latency of protools / scope / and 01v96....
the result is near the 0 point but i hear something wrong....
i have synchronise time code between samplitude ans protools...
i 'am so near the real time plugin recording system...
have you an idae to optimise my system
is there a realtime dsp asio sytem ? ( by analog device)
thanks for your reply phil weesch
i let a demos song of my system enjoy !
Welcome Aboard @weesch.
 
Top Bottom