I would sent my great apprecition for your work in this ASIO2 project. I definitly a kick ass plung we could benefit when using Foobar. Somehow, it comes to me a question about the Buffer Size with Sound Quality.
I'm running Foobar 1.3.10 in Win 10, connected with a USB (XMOS U8 solution)DDC -->DAC-->AMP-->Headphone.
For my understanding, my XMOS DDC is running in Isochronous/Async mode with FIFO buffer implemeted.Although have 2 seperate MCLK for 44.1 Khz or 48Khz mutiplier types music.
If I could take a wild guess, I would say the buffer size won't matter the sound quality to my DDC...but...IT Does.
I don't know why, though I do understand for an Async USB , in comparing with Adpative one, should get rid of jitter problem better but with no synchronous clock, the fidelity (or bit to bit) should be a problem. but here comes the FIFO buffers for it.
May I have any insight for this quesiton and I could definitely sleep better after it. Thanks and great work again.
Inlemar
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am happy that you feel an improvement with Asio2. Your question is good (which means that I don't have an obvious answer).
I agree with you that the endpoint buffer size should not really matter with a well designed asynchronous link between the player and the DAC. My primary purpose when developing the asio2 plugin was to improve my own system, based on a synchronous AES/EBU link between a lynx aes soundcard and my DAC, by minimizing the latency in the playback layer thanks to code optimization, especially in the driver callback. I don't know well the protocol used for the communication between the DAC and the driver on the player side in asynchonous usb but I guess that there is a sort of flow control or feedback from the sink endpoint (on the DAC side) to the source endpoint (the driver). Depending on the design of he driver, the responsiveness of the driver when dealing with this feedback, or the fifo size, could be influenced by the buffer size. Not sure that this explanation will help you to sleep better !
kind regards,
Didier
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your considerable explanation and you do did a good work in code optimization for your beloved project. Your answer is quite plausible and I concur with you in the "theorey" that maybe the driver side make some deals in the SQ question. I've had tried a blind test hours ago. With different ASIO driver versions of my XMOS based DDC, I could easily distinguish the different of the SQ variation versus Buffer Size setting, mostly from 64 samples to 8192 samples. Some version of the driver is less sensitive to the buffer size and some is. I could live with this result and try to sleep lefting it behind tonight.
One way or the other, It's always true of fact that I always get a way better SQ using ASIO2 and with no doubt, It always comes to me that your great effort and generousity in sharing it with us.
Thanks for your input again adn wish the best for your project.
Best,
Inlemar
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would sent my great apprecition for your work in this ASIO2 project. I definitly a kick ass plung we could benefit when using Foobar. Somehow, it comes to me a question about the Buffer Size with Sound Quality.
I'm running Foobar 1.3.10 in Win 10, connected with a USB (XMOS U8 solution)DDC -->DAC-->AMP-->Headphone.
For my understanding, my XMOS DDC is running in Isochronous/Async mode with FIFO buffer implemeted.Although have 2 seperate MCLK for 44.1 Khz or 48Khz mutiplier types music.
If I could take a wild guess, I would say the buffer size won't matter the sound quality to my DDC...but...IT Does.
I don't know why, though I do understand for an Async USB , in comparing with Adpative one, should get rid of jitter problem better but with no synchronous clock, the fidelity (or bit to bit) should be a problem. but here comes the FIFO buffers for it.
May I have any insight for this quesiton and I could definitely sleep better after it. Thanks and great work again.
Inlemar
Hello Inlemar,
I am happy that you feel an improvement with Asio2. Your question is good (which means that I don't have an obvious answer).
I agree with you that the endpoint buffer size should not really matter with a well designed asynchronous link between the player and the DAC. My primary purpose when developing the asio2 plugin was to improve my own system, based on a synchronous AES/EBU link between a lynx aes soundcard and my DAC, by minimizing the latency in the playback layer thanks to code optimization, especially in the driver callback. I don't know well the protocol used for the communication between the DAC and the driver on the player side in asynchonous usb but I guess that there is a sort of flow control or feedback from the sink endpoint (on the DAC side) to the source endpoint (the driver). Depending on the design of he driver, the responsiveness of the driver when dealing with this feedback, or the fifo size, could be influenced by the buffer size. Not sure that this explanation will help you to sleep better !
kind regards,
Didier
Hello Didier,
Thanks for your considerable explanation and you do did a good work in code optimization for your beloved project. Your answer is quite plausible and I concur with you in the "theorey" that maybe the driver side make some deals in the SQ question. I've had tried a blind test hours ago. With different ASIO driver versions of my XMOS based DDC, I could easily distinguish the different of the SQ variation versus Buffer Size setting, mostly from 64 samples to 8192 samples. Some version of the driver is less sensitive to the buffer size and some is. I could live with this result and try to sleep lefting it behind tonight.
One way or the other, It's always true of fact that I always get a way better SQ using ASIO2 and with no doubt, It always comes to me that your great effort and generousity in sharing it with us.
Thanks for your input again adn wish the best for your project.
Best,
Inlemar