XMC-1 USb is it Asynchronous?

[thezone]

Hi all,

I am getting a n XMC-1 and have a quick question.

I have read on this forum that it is best to use WASAPI with event style disabled or using WASAPI "Push Style" as the preferred output from a PC running JRMC . Asynchronous USB is, by definition, a ‘pull’ technology so by using this push style makes me wonder if the usb dac in the XMC-1 is asynchronous, Eg does the XMC-1 dac clock become the master?

Please let me know if I'm confused on this issue.

Thanks

[millst]

Yes, the CM6631A is asynchronous.

The WASAPI mode has nothing to do that. It deals with how the sound is moved between the user application (JRMC, in your case) and device driver. Event style (default) is superior in many ways, but either mode should sound the same (otherwise the data would be getting corrupt). The only reason to use the other mode is if your hardware has broken/buggy support for event style.

-tm

[geebo]

Feb 29, 2016 15:44:59 GMT -5 thezone said:

Hi all,

I am getting a n XMC-1 and have a quick question.

I have read on this forum that it is best to use WASAPI with event style disabled or using WASAPI "Push Style" as the preferred output from a PC running JRMC . Asynchronous USB is, by definition, a ‘pull’ technology so by using this push style makes me wonder if the usb dac in the XMC-1 is asynchronous, Eg does the XMC-1 dac clock become the master?

Please let me know if I'm confused on this issue.

Thanks

Not sure I understand your comment "Asynchronous USB is, by definition, a ‘pull’ technology..." I've never heard that before.

Keith, Any input on that?
KeithL

[KeithL]

That is indeed correct - although it's not normally phrased that way.

With the old isochronous USB mode, the computer was in charge of sending the data - controlled by its internal clock. That's why it was necessary for the DAC to "lock onto" the computer's clock using some method - like a PLL. The DACs clock could "follow" the computer's clock, and apply all sorts of smoothing to even it out, but it was basically forced to follow rather than lead - and even the fanciest PLL is basically a filter - and so can reduce but not totally eliminate variations in the incoming signal. (If you'd used an entirely independent clock in the DAC, you'd risk having the computer send data faster than you were receiving, and so having "extra bytes"; or, even worse, if the DAC got ahead of the computer, you could run out of audio data and end up waiting for the next sample.) This made it impossible to use an entirely separate, and better, local fixed clock in the DAC.

With an isochronous ASYNCHRONOUS connection, the DAC has its own internal clock, and the DAC "requests" that the computer send enough data to keep its buffer full. In detail, it's a little more complicated, and you can still run out of data if the computer simply fails to keep up, but the important part is that the DAC gets to control the data clock - using its own local high-quality clock, and so the DAC is relatively immune to both inconsistencies in timing from the computer's USB output clocking, and from jitter and timing errors that might occur in the cable or elsewhere along the way. (Unlike using an ASRC, or some other similar mechanism, to regenerate the data and lock it to a new clock, the USB data itself doesn't have to be recalculated, and so remains bit-perfect.)

(And, yes, the USB inputs on the XDA-2, the DC-1, the Ego DACs, and the USB Stream input on the XMC-1, are all asynchronous.)

WASAPI is a Windows internal communication mode - and is required to avoid having Windows re-sample everything you pass through it to a fixed sample rate. With Windows, audio output is "normally" resampled to whatever sample rate you have selected in the Sound Settings in Control Panel; there is no setting for "send it along at whatever sample rate you receive it at". For whatever mysterious reason, when WASAPI mode was added to bypass that, it was NOT made the default mode. (Actually it's not mysterious; if you have two different programs sending audio data at different sample rates, then at least one of them will have to be resampled because you can only mix two audio streams at the same sample rate - and Windows assumed this would be happening. So, for example, if you play a 96k audio file, but the system beeps and boops are at 44k, then either something will have to be resampled, or you won't be able to hear both at the same time.) WASAPI Push and WASAPI Event are mostly concerned with how Windows, the drivers, and your audio player interact - so the DAC doesn't care which one you use - but some player programs, and some drivers, may work better with one or the other. (Technically, since the clocking is controlled by the DAC, and both WASAPI modes should be bit-perfect unless something goes wrong, they should sound the same.... but some player/driver combinations have trouble with one or the other.)

Mar 1, 2016 10:33:41 GMT -5 geebo said:

Feb 29, 2016 15:44:59 GMT -5 thezone said:

Hi all,

I am getting a n XMC-1 and have a quick question.

I have read on this forum that it is best to use WASAPI with event style disabled or using WASAPI "Push Style" as the preferred output from a PC running JRMC . Asynchronous USB is, by definition, a ‘pull’ technology so by using this push style makes me wonder if the usb dac in the XMC-1 is asynchronous, Eg does the XMC-1 dac clock become the master?

Please let me know if I'm confused on this issue.

Thanks

Not sure I understand your comment "Asynchronous USB is, by definition, a ‘pull’ technology..." I've never heard that before.

Keith, Any input on that?
KeithL

[geebo]

Mar 1, 2016 11:20:24 GMT -5 KeithL said:

That is indeed correct - although it's not normally phrased that way.

With the old isochronous USB mode, the computer was in charge of sending the data - controlled by its internal clock. That's why it was necessary for the DAC to "lock onto" the computer's clock using some method - like a PLL. The DACs clock could "follow" the computer's clock, and apply all sorts of smoothing to even it out, but it was basically forced to follow rather than lead - and even the fanciest PLL is basically a filter - and so can reduce but not totally eliminate variations in the incoming signal. (If you'd used an entirely independent clock in the DAC, you'd risk having the computer send data faster than you were receiving, and so having "extra bytes"; or, even worse, if the DAC got ahead of the computer, you could run out of audio data and end up waiting for the next sample.) This made it impossible to use an entirely separate, and better, local fixed clock in the DAC.

With an isochronous ASYNCHRONOUS connection, the DAC has its own internal clock, and the DAC "requests" that the computer send enough data to keep its buffer full. In detail, it's a little more complicated, and you can still run out of data if the computer simply fails to keep up, but the important part is that the DAC gets to control the data clock - using its own local high-quality clock, and so the DAC is relatively immune to both inconsistencies in timing from the computer's USB output clocking, and from jitter and timing errors that might occur in the cable or elsewhere along the way. (Unlike using an ASRC, or some other similar mechanism, to regenerate the data and lock it to a new clock, the USB data itself doesn't have to be recalculated, and so remains bit-perfect.)

(And, yes, the USB inputs on the XDA-2, the DC-1, the Ego DACs, and the USB Stream input on the XMC-1, are all asynchronous.)

WASAPI is a Windows internal communication mode - and is required to avoid having Windows re-sample everything you pass through it to a fixed sample rate. With Windows, audio output is "normally" resampled to whatever sample rate you have selected in the Sound Settings in Control Panel; there is no setting for "send it along at whatever sample rate you receive it at". For whatever mysterious reason, when WASAPI mode was added to bypass that, it was NOT made the default mode. (Actually it's not mysterious; if you have two different programs sending audio data at different sample rates, then at least one of them will have to be resampled because you can only mix two audio streams at the same sample rate - and Windows assumed this would be happening. So, for example, if you play a 96k audio file, but the system beeps and boops are at 44k, then either something will have to be resampled, or you won't be able to hear both at the same time.) WASAPI Push and WASAPI Event are mostly concerned with how Windows, the drivers, and your audio player interact - so the DAC doesn't care which one you use - but some player programs, and some drivers, may work better with one or the other. (Technically, since the clocking is controlled by the DAC, and both WASAPI modes should be bit-perfect unless something goes wrong, they should sound the same.... but some player/driver combinations have trouble with one or the other.)

Mar 1, 2016 10:33:41 GMT -5 geebo said:

Not sure I understand your comment "Asynchronous USB is, by definition, a ‘pull’ technology..." I've never heard that before.

Keith, Any input on that?
KeithL

Thanks for that, Keith.

[geebo]

Feb 29, 2016 15:44:59 GMT -5 thezone said:

Hi all,

I am getting a n XMC-1 and have a quick question.

I have read on this forum that it is best to use WASAPI with event style disabled or using WASAPI "Push Style" as the preferred output from a PC running JRMC . Asynchronous USB is, by definition, a ‘pull’ technology so by using this push style makes me wonder if the usb dac in the XMC-1 is asynchronous, Eg does the XMC-1 dac clock become the master?

Please let me know if I'm confused on this issue.

Thanks

See Keith's explanation above. Also this is excerpted from a pdf on the Emo site here:

emotiva.com/resources/updates/Configuring_WASAPI_Mode_in_Audio_Players.pdf

"Configuring jRiver Media Center v20 To Use WASAPI Mode
To configure WASAPI Mode in jRiver Media Center, do the following:
1. (If you haven’t already) install and run the jRiver Media Center program.
2. Under the Tools menu, go to Options.
3. Select the Audio category.
4. On the right, under Audio Device, select USB2.0 High-Speed True HD Audio (WASAPI).
5. Now, under Audio Device, click Device Settings.
(This option won’t be available until you select the Audio Device in the previous step).
6. In Device Settings...
Check the box next to Open device for exclusive output.
Check the box next to Disable event style.
Leave Bit Depth set to Automatic.
Leave Buffering set to 100 milliseconds.
7. Click OK twice to save your settings and exit.
NOTE: For each source sample rate, jRiver Media Center can be independently configured
to convert files of that sample rate to a specified sample rate, or to play them at their native
sample rate. For “bit perfect playback”, you want each file to play at its native (unconverted)
sample rate. However, there are certain situations where converting the sample rate can be
useful. For example, the XDA-2 doesn’t support 176k via USB (it does support 176k on its
other inputs). Therefore, if you wish to play 176k files on your XDA-2 using jRiver, you should
configure jRiver to play 176k files at 192k.
NOTE: Windows “itself”, and Windows Media Player, do NOT use WASAPI Mode. WASAPI
Mode must be configured in EACH player program that you wish to use it with. Configuring
WASAPI Mode in jRiver Media Center will NOT configure Windows itself, or other Windows
audio player programs (including Windows Media Player) to use WASAPI."

[thezone]

Thanks KeithL, now I have a good understanding of how it all works. I had done quite a lot of research on this before posting and you have provided the last piece of the puzzle thank you!. There is nothing in the XMC-1 promotional material nor in the manual (I did read that expert from the manual thanks geebo) that mentions whether the USB DAC is Asynchronous. Given its such a buzz term in audiophile world you think they would put this on the website. The Cambridge Audio Receiver Azur751R V2 lists its Asynchronous USB Dac clearly on the website.
Just a thought.

Thanks again I appreciate it.

[garbulky]

Mar 1, 2016 11:20:24 GMT -5 KeithL said:

That is indeed correct - although it's not normally phrased that way.

With the old isochronous USB mode, the computer was in charge of sending the data - controlled by its internal clock. That's why it was necessary for the DAC to "lock onto" the computer's clock using some method - like a PLL. The DACs clock could "follow" the computer's clock, and apply all sorts of smoothing to even it out, but it was basically forced to follow rather than lead - and even the fanciest PLL is basically a filter - and so can reduce but not totally eliminate variations in the incoming signal. (If you'd used an entirely independent clock in the DAC, you'd risk having the computer send data faster than you were receiving, and so having "extra bytes"; or, even worse, if the DAC got ahead of the computer, you could run out of audio data and end up waiting for the next sample.) This made it impossible to use an entirely separate, and better, local fixed clock in the DAC.

With an isochronous ASYNCHRONOUS connection, the DAC has its own internal clock, and the DAC "requests" that the computer send enough data to keep its buffer full. In detail, it's a little more complicated, and you can still run out of data if the computer simply fails to keep up, but the important part is that the DAC gets to control the data clock - using its own local high-quality clock, and so the DAC is relatively immune to both inconsistencies in timing from the computer's USB output clocking, and from jitter and timing errors that might occur in the cable or elsewhere along the way. (Unlike using an ASRC, or some other similar mechanism, to regenerate the data and lock it to a new clock, the USB data itself doesn't have to be recalculated, and so remains bit-perfect.)

(And, yes, the USB inputs on the XDA-2, the DC-1, the Ego DACs, and the USB Stream input on the XMC-1, are all asynchronous.)

WASAPI is a Windows internal communication mode - and is required to avoid having Windows re-sample everything you pass through it to a fixed sample rate. With Windows, audio output is "normally" resampled to whatever sample rate you have selected in the Sound Settings in Control Panel; there is no setting for "send it along at whatever sample rate you receive it at". For whatever mysterious reason, when WASAPI mode was added to bypass that, it was NOT made the default mode. (Actually it's not mysterious; if you have two different programs sending audio data at different sample rates, then at least one of them will have to be resampled because you can only mix two audio streams at the same sample rate - and Windows assumed this would be happening. So, for example, if you play a 96k audio file, but the system beeps and boops are at 44k, then either something will have to be resampled, or you won't be able to hear both at the same time.) WASAPI Push and WASAPI Event are mostly concerned with how Windows, the drivers, and your audio player interact - so the DAC doesn't care which one you use - but some player programs, and some drivers, may work better with one or the other. (Technically, since the clocking is controlled by the DAC, and both WASAPI modes should be bit-perfect unless something goes wrong, they should sound the same.... but some player/driver combinations have trouble with one or the other.)

Mar 1, 2016 10:33:41 GMT -5 geebo said:

Not sure I understand your comment "Asynchronous USB is, by definition, a ‘pull’ technology..." I've never heard that before.

Keith, Any input on that?
KeithL

Here's something that bugs me about the new WASAPI. It used to be that when WASAPI was engaged nothing could interrupt it. But now with the new push pull options any time some random thing on windows plays it basically intrerupts the wasapi stream! Any idea on how to bypass that?

[yves]

Mar 1, 2016 17:33:36 GMT -5 garbulky said:

Mar 1, 2016 11:20:24 GMT -5 KeithL said:

That is indeed correct - although it's not normally phrased that way.

With the old isochronous USB mode, the computer was in charge of sending the data - controlled by its internal clock. That's why it was necessary for the DAC to "lock onto" the computer's clock using some method - like a PLL. The DACs clock could "follow" the computer's clock, and apply all sorts of smoothing to even it out, but it was basically forced to follow rather than lead - and even the fanciest PLL is basically a filter - and so can reduce but not totally eliminate variations in the incoming signal. (If you'd used an entirely independent clock in the DAC, you'd risk having the computer send data faster than you were receiving, and so having "extra bytes"; or, even worse, if the DAC got ahead of the computer, you could run out of audio data and end up waiting for the next sample.) This made it impossible to use an entirely separate, and better, local fixed clock in the DAC.

With an isochronous ASYNCHRONOUS connection, the DAC has its own internal clock, and the DAC "requests" that the computer send enough data to keep its buffer full. In detail, it's a little more complicated, and you can still run out of data if the computer simply fails to keep up, but the important part is that the DAC gets to control the data clock - using its own local high-quality clock, and so the DAC is relatively immune to both inconsistencies in timing from the computer's USB output clocking, and from jitter and timing errors that might occur in the cable or elsewhere along the way. (Unlike using an ASRC, or some other similar mechanism, to regenerate the data and lock it to a new clock, the USB data itself doesn't have to be recalculated, and so remains bit-perfect.)

(And, yes, the USB inputs on the XDA-2, the DC-1, the Ego DACs, and the USB Stream input on the XMC-1, are all asynchronous.)

WASAPI is a Windows internal communication mode - and is required to avoid having Windows re-sample everything you pass through it to a fixed sample rate. With Windows, audio output is "normally" resampled to whatever sample rate you have selected in the Sound Settings in Control Panel; there is no setting for "send it along at whatever sample rate you receive it at". For whatever mysterious reason, when WASAPI mode was added to bypass that, it was NOT made the default mode. (Actually it's not mysterious; if you have two different programs sending audio data at different sample rates, then at least one of them will have to be resampled because you can only mix two audio streams at the same sample rate - and Windows assumed this would be happening. So, for example, if you play a 96k audio file, but the system beeps and boops are at 44k, then either something will have to be resampled, or you won't be able to hear both at the same time.) WASAPI Push and WASAPI Event are mostly concerned with how Windows, the drivers, and your audio player interact - so the DAC doesn't care which one you use - but some player programs, and some drivers, may work better with one or the other. (Technically, since the clocking is controlled by the DAC, and both WASAPI modes should be bit-perfect unless something goes wrong, they should sound the same.... but some player/driver combinations have trouble with one or the other.)

Here's something that bugs me about the new WASAPI. It used to be that when WASAPI was engaged nothing could interrupt it. But now with the new push pull options any time some random thing on windows plays it basically intrerupts the wasapi stream! Any idea on how to bypass that?

wiki.jriver.com/index.php/Exclusive_Access

1. Open the Sound control panel in Windows
2. Select your device and click Properties.
3. Switch to the Advanced tab.
4. Ensure that Allow applications to take exclusive control of this device and Give exclusive mode applications priority are both enabled.

[garbulky]

yves. I should have mentioned this issue is for Foobar. Give applications exclusive control is checked on the windows Vista sound control panel but there is no option for it I can see in Foobar

[millst]

The application itself has to request exclusive mode. The sound control panel setting only determines whether Windows will allow or deny the request.

-tm