Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[manisiutkin]

When in DSD bitstream mode MC17 uses 352800 for IASIO::setSampleRate call instead of plain 64Fs (as suggested in ASIO SDK). Could you please comment this?

[Matt]

Hi, and welcome to Interact.

With DSD bitstreaming, we expect ASIO formats ASIOSTDSDInt8LSB1 or ASIOSTDSDInt8MSB1.

In this format, 8 DSD bits are packed into a sample of one byte.

So in 2.8 MHz DSD, this means there are 352800 samples (each containing 8 DSD bits) per second per channel.

This is the system Playback Designs hardware requires (they were the first company to send us DSD-compatible hardware for testing).

[manisiutkin]

Thank you for welcoming! Seems that I stupidly used 64Fs/128Fs as ASIO samplerates
Here're two more questions then:

1. Do other DSD playback devices use the same scheme 352800 / 8 bits?

2. How do you deal with 128Fs DSD streams? Is it 352800 / 16 bits or something else?

[Matt]

1. Do other DSD playback devices use the same scheme 352800 / 8 bits?

Playback Designs is the only device we've had the chance to test first hand.

2. How do you deal with 128Fs DSD streams? Is it 352800 / 16 bits or something else?

2x DSD will use 705600 as the sample rate, and still 8 DSD bits per sample.


I should note that we're open to supporting other hardware schemes if there's a need, so just let us know.

[manisiutkin]

I should note that we're open to supporting other hardware schemes if there's a need, so just let us know.

The reason why I'm asking is that: foobar sacd plugin can do direct DSD playback through ASIO too, but it sets samplerates to 64Fs or 128Fs. Not having the real DSD playback device I wrote for testing purposes some "DSD ASIO enhancer" for the regular ASIO (with the DSD->PCM coverter inside). And yesterday I discovered that this "enhancer" doesn't work with MC17 . Would be great to have some "reference" scheme for DSD ASIO playback since there is more than one DSD capable DAC on the market.

[Blaine78]

i'd like to see JRiver ASIO DSD direct streaming work with the new Mytek DSD DAC.

[pacwin]

To make ASIO support happen the Mytek ASIO driver has to be redeveloped to include DSD bitstreaming capabilities (looks like this would be Firewire initially). Mytek are dragging their feet with this. However what does work with the Mytek Firewire/DICE driver is the dCs byte packing scheme (specification here: http://www.computeraudiophile.com/files/DSD%20over%20USB.pdf). This is sending a packed version of DSD (176/16) with an 8bit padding identifying the stream as actually DSD. The Mytek firmware 1.20 knows how to decode this stream in its FPGA. One other Windows application can reliably send this DCs packed scheme but its not a patch on JRiver's feature set. Pending Mytek getting its act together those of us who are JRiver owners are currently unable to play native DSD. One solution would be to have a dCs option in JRiver MC which is very similar to the packing scheme for the Playback Designs DAC.

"As you can see, the top 8 bits of each sample are 0xAA. This represents a negative DC offset, which won't be seen in real‐life audio, so we can use it as an indicator for the DAC that the data it is receiving is DSD rather than 24/176.4 PCM. Additionally, it means that if we try and play the DSD stream via a DAC that doesn't support it, the output is noise, but it is 48dB down ‐ the user can tell they are playing back an unsupported format, but not in a speaker‐destroying way. For PC‐audio based solutions, if the playback software is DSD‐aware, it can output 0xAAAAAA samples by default
to represent a safe DSD mute." (Playback of DSD Audio over USB – A Suggested Open Standard)


 As it stands now JRiver is potentially losing prospective (not current!) customers to the functionally inferior competition by users who have DSD and a Mytek DSD Dac and no way to convey it across the wire using JRiver.  I have plenty of DSD files and a Mytek DAC and am willing to test any attempt on JRiver's part to implement the dCS scheme.  I will also lobby Mytek to send a loan Mytek DAC to JRiver for testing.

A second desirable feature would be the ability to write Id3v2 tags to the Sony *.DSF file used to store uncompressed DSD. This specification is also well defined (http://www.dsd-format.sony.net/en/index.php) and not proprietary.

[manisiutkin]

To make ASIO support happen the Mytek ASIO driver has to be redeveloped to include DSD bitstreaming capabilities (looks like this would be Firewire initially).

Actually, the situation with Mytek seems to be a bit different. Mytek ASIO driver (as the hardware USBPAL interface) is developed by RigiSystems AG and at present time has native DSD support. So, the only Mytek firmware has to be redeveloped.    

[manisiutkin]

With the latest 62 version direct DSD playback is fine (although ASIO driver needs to translate samplerates to the familiar DSD64/128). There are some additional questions to ask:

1. The DSD output device has only 2 channels and it would be nice to have some "routing" scheme on "ASIO Settings" panel (which of the source channels to send to device in case of multichannel DSD). Does it sound sound?

2.  DSD playback lacks of some features like DST (DSD compressed) .dff and SACD ISO playback. Could it be, in principle, implemented in some input plugin? Is the J River SDK enough for doing this? This plugin would need to show SACD tracks like CD plugin does, and to send DSD stream down to the output.  

[pacwin]

Actually, the situation with Mytek seems to be a bit different. Mytek ASIO driver (as the hardware USBPAL interface) is developed by RigiSystems AG and at present time has native DSD support. So, the only Mytek firmware has to be redeveloped.    

Recent items on the Mytek DSD thread on computeraudiophile.com indicate from Mytek staff  that the delay is with Rigisystems AG in Switzerland.
http://www.computeraudiophile.com/content/Mytek-Stereo-192

If you interrogate the Rigisystems ASIO driver it reports DSD capability but it is not actually working with DSD bitstreams. Try using that ASIO driver with a DAW like REAPER and it chokes on the ASIO driver. There is something  flawed. PCM is perfectly fine. The most important outstanding firmware issue for Mytek is reversed channels on DSD playback. The only current native DSD solution on Windows with the Mytek is the dCS byte packing scheme and you are forced to use Signalyst HQ Desktop to do that. Impoverished software compared to JRiver but the signal processing is all good.

Also I think you will find that Firewire ASIO will be supported before USB ASIO on Windows.

Its not clear yet that the JRiver ASIO byte scheme for Playback Designs will work with Mytek firmware.

>>[From another thread]I should note that we're open to supporting other hardware schemes if there's a need, so just let us know.

Another option for JRiver is to use the dCs packing scheme. Not too difficult to implement. At least we know that works with the Mytek firmware. This has been requested a number of times and I would like to ask that it be considered again. JRiver is unbeatable for managing large file collections but right now we have to sneak away somewhere else to play back our DSD files. That should give you two DACS working with JRiver with one change: dCs and Mytek .

There is one other DAC, a hobbyist implementation that is reportedly working with ASIO and J River conveying DSD over USB

http://exd-audio.blogspot.com/2012/01/support-j-river-media-center-dsd.html

I guess we can only hold out until Rigisystems pony up their ASIO driver. That would save some effort on Jrivers part. If its a lemon or unreasonably delayed. I think we should revisit the dCS option.

[manisiutkin]

From my point of view the real obstacle with the DSD playback is that the current ASIO specification is too vague about DSD. As the result there are a few different and incompatible ASIO DSD implementations. Don't think that Steinberg will review its ASIO spec about DSD. Can offer two possible solutions:

1. Someone (and J River is good for that) should clarify DSD interface in ASIO spec and others follow. This is the best possible case. Suppose, if J River has developed DSD plugin it might be interested in the future of direct DSD playback too

2. It is possible to have ASIO "swichboard" extra layer (separate ASIO driver) which can connect incompatible DSD players and devices. But who will do this?

[rigi]

Recent items on the Mytek DSD thread on computeraudiophile.com indicate from Mytek staff  that the delay is with Rigisystems AG in Switzerland.
http://www.computeraudiophile.com/content/Mytek-Stereo-192

If you interrogate the Rigisystems ASIO driver it reports DSD capability but it is not actually working with DSD bitstreams. Try using that ASIO driver with a DAW like REAPER and it chokes on the ASIO driver. There is something  flawed.

RigiSystems ASIO driver is supporting DSD since 2008. And contrary to the statement above it is working with native DSD streams. The problems are more related to how different players interpret the rather imprecise ASIO specification from Steinberg. While the ASIO driver had been tested by two very well known Japanese MI and CE companies, for many years nobody cared much for DSD. Everyone seems to face the problem how to interpret the spec.. Basically incompatibilities arise from the lack of any sequence diagrams and limited information in what state which functions are allowed and the spec. seems to interpreted differently by some players which allocate buffers in Byte size instead of sample sizes for DSD. Some information can only implicitly retrieved from the Steinberg SDK code. Our drivers are extensively tested against the most important DAWs (especially Steinbergs CuBase) for PCM and we are supporting everyone who intents to implement DSD on their player.

[Ychng]

Thanks for chiming in here, Rigisystems. We have been talking about this on this forum and many others.

Regardless of the cause, ASIO bitstreaming with JRiver still does not work. I guess the fault could be with any of the 3 parties involved, Mytek, JRiver or Rigisystems. Michal of Mytek says that he has been pushing Rigisystems for the longest time to fix some DSD issues with the driver.
If the foobar SACD plugin team managed to come up with a solution that works for foobar, how much work does it involve on the rigisystems end?

Thanks a lot for all your efforts in any case.

Yeang

[pacwin]

RigiSystems ASIO driver is supporting DSD since 2008. And contrary to the statement above it is working with native DSD streams. The problems are more related to how different players interpret the rather imprecise ASIO specification from Steinberg. While the ASIO driver had been tested by two very well known Japanese MI and CE companies, for many years nobody cared much for DSD. Everyone seems to face the problem how to interpret the spec.. Basically incompatibilities arise from the lack of any sequence diagrams and limited information in what state which functions are allowed and the spec. seems to interpreted differently by some players which allocate buffers in Byte size instead of sample sizes for DSD. Some information can only implicitly retrieved from the Steinberg SDK code. Our drivers are extensively tested against the most important DAWs (especially Steinbergs CuBase) for PCM and we are supporting everyone who intents to implement DSD on their player.

This is somewhat of a red herring and its also late in the day, nearly six months since it became clear the ASIO drivers do not work out of the box, to be publicly offering support. Its no help to a Mytek DAC owner who are reliant on your driver engineering to say that your drivers are extensively tested against the most important DAW's for PCM. No one has a problem with PCM over ASIO using USBPAL. Neither is it useful to point to unnamed Japanese companies. And as far as I know Steinberg never implemented DSD use in any of their DAW's. We are interested in how you are helping Mytek and JRiver get Native DSD working over your ASIO driver. Surely there is plenty of scope to set any parameters, byte packing schemes(LSB, MSB) or buffer sizes in the USBPAL Control panel. Why dont you consider open sourcing the ASIO driver?. There's plenty of people who would be happy to contribute to what should be a fairly straightforward project. In my view Rigisystems is potentially putting its reputation at risk. The fiasco with Mytek may well put off users looking at other implementations of USBPAL.

The Playback Designs USB DAC is working with their ASIO driver and JRiver. According to a thread on this forum the JRiver bitstreaming over ASIO expects/sends data as ASIO formats ASIOSTDSDInt8LSB1 or ASIOSTDSDInt8MSB1 which is equivalent to 352.8/8 data rate (705.6/8 for DSD 128fs). Is that what the FPGA code in the Mytek DAC is expecting?

In any event we may have a work around with JRiver, much to their credit, who have stated they are committed to supporting the dCS byte packing scheme. However that scheme does not define support for DSD 128fs and in general most would prefer the elegance of the ASIO driver in the longer term. At leasst that might buy you some time.

[JimH]

rigi,
Thanks for posting here.  We'll do what we can to support you.

pacwin,
This area is fairly new for us and for many others.  There are also some standards coming that may help, so just give us a little time.

[In2Win]

I have not been terribly impressed with rigisystems support! I'm not sure if it is that they don't understand English well or if they just choose to only deal with OEM's? My guess is it is a bit of both. you have to be an OEM to purchase their products and they only sell eval versions of the products anyway.  they do give you an SDK with the eval kit but it is only for the control panel and only comes with a driver that beeps every 5 minutes! you have to pay a lot extra, as in thousands, to get fully working drivers/software!


I really wish they would do something open source! but they wouldn't make money that way! I gave up on them.