I had an issue for which I asked Audirvana for help but not resolved yet.
So I post this topic again as I found something new, and wanna see if I can get some new feedback not only from Damiens, but also users having similar problems.
Here’s the detail:
-
USB Device: Weiss INT204, XMOS based USB digital-to-digital converter, able to receive & process DSD over PCM format audio data via ASIO
-
Audirvana version: Windows 10, 3.5.xx
-
Debug Info, Download from this link:
- This issue is not related with PCM Upsampling. It happens when Upsampling is disabled too.
5. Here’sWhat happend:
If I play tracks in a specific pattern:
PCM track
–switch_to–>
DSD track no.1
-switch_to–>
DSD track no.2 & switch to more DSD tracks
From the moment DSD track no.2 start loading:
5.1 Some ugly noise can be heard for about 0.5s, at the beginning of the track from my audio system.
5.2 Same noise can be heard If you pause the track(not fully stop it)
5.3 The app has a certain chance to crash during the “track switch” moment, happens 100% after switching to more DSD tracks.
5.4 When Audirvana crashes, it generates minidump file. Loud pulsating noise can be heard from audio system until I kill the process of the app.
5.5 During “abnormal track pausing” & app crashing, LED indicator of my USB device keep flickering between DSD & PCM modes, this happens along with the noise sound.
After a long E-mail disccusion with Audirvana support team, I was told they were not able to help as the issue lay on the ASIO Driver layer.
But, by reading DOP open standard, and managing to capture USB raw data sent to my USB device in real time, I found some new clue from which I thought the issue was very likely caused by Audirvana.
Here’s What I got:
1. Accoding to DOP open standard, 8 bits are used for the DSD marker and alternate with each sample between 0x05 and 0xFA. This is some random DOP format data I captured:
Real PCM data does not have this pattern, here’s some example:
2. To pause playing DSD track(not full stop), the DOP method is keep sending fixed DSD data in DOP format to lock device on DSD mode, for example this is the Audirvana “009696” pattern:
I also see another pausing data pattern “006969”, from JRiver Media Center as the software to play DSD track in DOP format.
When I was monitoring USB raw data in real time, The “009696FA” “00969605” pattern can be seen during Audirvana is pausing a DSD song, or switching to another DSD track, also can be seen when you switch DSD to PCM, I guess it has following functions:
– keep USB device locking on DSD mode
– keep the whole audio system quiet
thus it is repeated during track pause, and used to fill the gaps caused by loading new DSD tracks.
Until now things look perfect.
3. Problem is, “009696FA” “00969605” pattern is not always “clean”. Often some unclean data (non-DOP format) can be observed, mixing with “009696” pattern, keep looping and feeding to my USB device, for example:
even some crazy stuff like this:
Obviously not audio data at all…
Imagine this non-DOP data keep looping and feeding to my device… No wonder the LED indicator flickers between PCM & DSD modes, and the noise was generated… by the unclean stuff which my device took them as PCM audio data and make them sound…
This might also explain why Audirvana(Win10) generates popping noise when switching track but JRiver doesn’t, even I play only DSD tracks (which is not gonna crash the app).
To make you understand better what was happening, download:
A small chunk of data captured during the “unclean DSD track pause”:
And how it sounds like during unclean pause, an 1MB size video, :
And Screen captured video of “unclean DSD track loading & pause”, with realtime USB Raw data view:
https://drive.google.com/drive/folders/1RHb7WwGLC1-cTpj1Sv5VSGpes-oAu5S0?usp=sharing
video size 9MB, easy download
please download to watch above videos, web preview not clear enough to see data.
So why do I think it is most probably caused by bug from Audirvana？
4. In the case of DSD over PCM, audio data follows this path:
Audirvana → ASIO Driver → USB protocol → physical device
I believe packing DSD into DOP format is done by Audirvana side(let me know if I’m wrong), then DOP data shall be bit perfect all the way to actual USB hardware, which means technically ASIO Driver does not make any change on audio data content received from Audirvana, especially in the case of DSD over PCM.
If this is true, it is very likely that Audirvana was feeding unclean DOP data to ASIO Driver.
However I’m not 100% sure, it could be ASIO Driver’s fault to let in unclean data. I also mailed to device vendor for advice.
5. My specific track switching pattern triggers the “unclean pause” & app crash. If I only play DSD64 tracks after starting Audirvana, it won’t happen. ASIO is something on the driver layer, which is a low level & direct path. I don’t think its stability could be such “case sensitive” to my operation on a player app.
6. Jriver & Foobar does not crash working with Weiss INT204 in DOP mode.
7. Look at the “unclean” Non-audio data I captured:
we can recover text like “windows\assembly\nativeimage”. That’s a bunch of Microsoft .NET related error info… could this kind of data generated by a low level ASIO driver? Nah…
So what do you think？
I think this could be a common issue among Audirvana DOP mode user, at lease I know another XMOS based device user having the same issue, see this thread:
But I got no chance to test Audirvana with another device in DOP mode, simply because Weiss INT204 is the only available one to me.
P.S. , funny thing is, my AudioByte HydraZ works in DOP mode with JRiver, but not the same case with Audirvana(DSD native). Or I’ll tell the unclean data is “device specific” or not…
