Topic: DSD testing (Read 8752 times)

hifi25nl · « **on:** February 14, 2014, 06:31:20 am »

I am testing DSD output in MediaCenter with an Amanero card with passive output filter.

As in Windows if I set Bitstreaming Yes I have sound with a lot of noise (I think this is specific to the card)

If I set:
Bitstreaming -- > none
2xDSD in Dop format or (1x)DSD in Dop format I have sound output for only one channel (in my case only left channel)
(I hope that in this second case there is no real conversion to PCM)

Note: very happy that now I can set buffer time and period time in alsa!

hifi25nl · « **Reply #1 on:** April 22, 2014, 04:50:34 pm »

Please can you fix this? The same configuration in Windows is working fine.
Here in Linux the left channel is completely muted.

bob · « **Reply #2 on:** April 22, 2014, 05:03:55 pm »

Quote from: hifi25nl on April 22, 2014, 04:50:34 pm

Please can you fix this? The same configuration in Windows is working fine.
Here in Linux the left channel is completely muted.

No idea.
What ALSA device settings choice are you using in MC's audio options?

hifi25nl · « **Reply #3 on:** April 23, 2014, 06:15:51 am »

I am using the same settings that are working fine in PCM:
iec958:CARD=Amanero,DEV=0

I have found that with other applications the same situation arise when the DSD streaming is not sent in the correct DoP format.
However bitstreaming is set to none, so the output should be DoP.

InflatableMouse · « **Reply #4 on:** April 23, 2014, 06:35:38 am »

The last time I tried (before I got the new NUC with Win8.1 to replace the old HTPC) I was using my DAC via a Linux host with MC. DoP wasn't working, but native DSD output was.

I will hook up my DAC to my PC one of these days and let you know whether DoP works with newer versions of MC.

My DAC is a Teac UD-501, USB.

InflatableMouse · « **Reply #5 on:** April 28, 2014, 03:55:15 am »

Under Linux:

Output Mode: None
All DSD files play (1x or 2x, dff, dst, dsf or sacd iso).
AudioPath correctly shows input and output formats.
DAC Display shows everything correctly

Everything plays fine.

Output mode set to DoP 1x or 2x
AudioPath shows input and output correctly.
DAC Display says PCM 176.4 or 352.8 kHz. This is incorrect, it should display DoP format.

MC is playing (time progresses) but there is no sound, the DAC is not recognizing the stream as DoP, it thinks its PCM.

Bitstreaming DSD
AudioPath shows input DoP and output as DoP (bitstreaming). This is not correct. Input and output should say DSD 2.8 or 5.6MHz.
When bitstreaming 1x or 2xDSD files, the DAC displays the same thing as with output mode set to DoP. The DAC's display should show DSD 2.8 or 5.6MHz.

There is no sound (same as above).

With MC for Windows:
1x or 2xDSD in DoP: DAC Display will show DoP format, DSD 2.8 or 5.6MHz
2xDSD Native: DAC Display will only show DSD 2.8 or 5.6MHz.
AudioPath will show input and output correctly as PCM or DSD or DoP, with the correct sampling rates, same when bitstreaming.

Everything plays fine with Windows.

hifi25nl · « **Reply #6 on:** April 28, 2014, 03:33:07 pm »

At least in Dop 2x I can hear one channel...

So there is some fix to be made.

The only reference I have found on DSD and alsa is a little old,
see:
http://mailman.alsa-project.org/pipermail/alsa-devel/2013-April/061239.html

bob · « **Reply #7 on:** April 29, 2014, 10:11:04 am »

That's enough to tell me that it's not going to work as configured.
We only open the output device in PCM mode.

InflatableMouse · « **Reply #8 on:** April 29, 2014, 10:58:05 am »

So its an easy fix then?

bob · « **Reply #9 on:** May 05, 2014, 11:25:58 am »

Had a chat with Matt on this and he believes that the device driver should know that it's getting Dop based on the header.
We shouldn't have to open it in any specific mode.

The link was interesting and it's possible the ALSA driver isn't new enough to deal with this issue yet.

InflatableMouse · « **Reply #10 on:** May 05, 2014, 12:52:03 pm »

I doubt I have an old driver, being on Arch and all. But to be sure, I'll see how I can check this. I think that patch was over a year old?

Edit: I wasn't sure whether the ALSA package version was also the driver version. I have alsa-lib 1.0.27.2-1. This is the latest according to ALSA project page.

InflatableMouse · « **Reply #11 on:** May 05, 2014, 01:19:40 pm »

According to this guy, DSD is working, at 1x.

bob · « **Reply #12 on:** May 05, 2014, 02:10:35 pm »

Hard to know what the issue is here.
In windows we simply provide the device driver with Dop wrapped PCM and it knows what to do.
Perhaps linux can't handle that.
I find this suspicious:
dsd_usb "yes"

InflatableMouse · « **Reply #13 on:** May 05, 2014, 03:09:40 pm »

Yeh I noticed that too, its MPD's config file and I'm not sure what that means. I'll see if I can learn something about that tomorrow.

hifi25nl · « **Reply #14 on:** May 07, 2014, 03:16:39 am »

DSDin linux is working fine with MPD and HQplayer. With HQ player (in DoP mode) is possible to upsample to DSD128.

For what I know 'dsd_usb "yes"' simply activate DoP markers. I think all this is working only if alsa mixer is DISABLED.
For example in my MPD configuration I have --> mixer_type "disabled"

I guess the mixer cannot handle a stream with Dop markers.

P.S.

I have checked JRiver and I have not discovered an option to disable alsa mixer.

bob · « **Reply #15 on:** May 08, 2014, 10:25:18 am »

When you use the internal volume control we don't open or touch the ALSA mixer (internal volume was the only one that worked up until recent releases).

Quote

For what I know 'dsd_usb "yes"' simply activate DoP markers.

It's not clear what this means. When we use send the DoP it's already "marked" as such.
Since the rendering device doesn't play it I assume the ALSA device is being opened differently somehow.
If you have logging turned on, you can see how the device is being opened in the logs.

InflatableMouse · « **Reply #16 on:** May 08, 2014, 10:28:36 am »

Quote from: bob on May 08, 2014, 10:25:18 am

When you use the internal volume control we don't open or touch the ALSA mixer (internal volume was the only one that worked up until recent releases).

So maybe this is the problem. I use internal volume on front:-device but the volume controls in XFCE still work. If ALSA is trying to regulate volume on a DoP stream wouldn't it corrupt the stream?

bob · « **Reply #17 on:** May 08, 2014, 10:34:30 am »

Quote from: InflatableMouse on May 08, 2014, 10:28:36 am

So maybe this is the problem. I use internal volume on front:-device but the volume controls in XFCE still work. If ALSA is trying to regulate volume on a DoP stream wouldn't it corrupt the stream?

Perhaps but it seems to me that if you are using the front: device you are already bypassing any control the XFCE mixer has.
Now it's possible that simply having the xfce mixer open (or pulseaudio installed) could cause trouble.

InflatableMouse · « **Reply #18 on:** May 10, 2014, 04:18:08 am »

I've started testing some more with this.

I have a question, maybe its gone unnoticed in my post above, but when I bitstream a DSD file (dsf), Audio Path shows input: DoP. This is not correct. Maybe its just displaying incorrectly I don't know.

InflatableMouse · « **Reply #19 on:** May 11, 2014, 05:56:36 am »

I did some more testing and troubleshooting and got some great help from a guy over at the Arch forums too.

First of all, I have only lib-pulse installed, not pulseaudio. There is no pulse process/daemon running, pulse is not active. The libraries are required only to satisfy a dependency nothing more.

Created a new device which lists with aplay -L, which MC can select and use. In ~/.asoundrc I placed the following:

Code: [Select]

pcm.ud501hw {	type hw;
		card "UD501";
		device 0;
		subdevice 0;	}

pcm.ud501 {	type plug;
                slave.pcm "ud501hw";
                hint {  show on;
		description "Teac UD501 USB DAC";	}	}

To make sure the default device is NOT set to UD501, I also added the following to .asoundrc:

Code: [Select]

pcm.!default {
	type hw
	card ST
	device 0
	subdevice 0
}

ctl.!default {
	type hw
	card ST
	device 0
	subdevice 0
}

This sets the default device to the Asus Xonar ST.

Output to "ud501" goes straight to the hardware, there is no mixing involved whatsoever.

The results with DSD output from MC are actually the same as before, but now we can exclude pulse and/or any mixer/volume control involvement.

To sum it up:
when a DSD file is bitstreamed, audiopath shows input DoP, output DoP. The DAC's display does not switch to DSD or DoP, it shows PCM 178.4kHz.
When DoP is selected for output mode, audiopath shows output as DoP, but again the DAC shows PCM and DoP at 178.4/356.8kHz.

Maybe unrelated, but when bitstreaming a DSD file, audiopath on Windows shows DSD file. Linux shows DoP in that case.

bob · « **Reply #20 on:** May 12, 2014, 04:02:10 pm »

If you are testing bitstreaming, you should have the DSP studio output formatting turned OFF.
That is a conversion. We need to start with this off to reduce the number of variables we are testing.

Now the default when sending a dsf file to a device is to format it in DoP.
This is why you are seeing DoP input, DoP output in the audiopath when you turn bitstreaming DSD on.

The device is supposed to play this through the PCM driver.

Comparing to Windows and Mac.
The Mac cannot play non-DoP DSD.
Windows can ONLY play it in ASIO mode, it appears to us this requires some special driver work.

We are curious as to why you cannot play the DoP format DSD on your device with output format turned off (and mixer disabled).

InflatableMouse · « **Reply #21 on:** May 13, 2014, 12:47:42 am »

Quote from: bob on May 12, 2014, 04:02:10 pm

If you are testing bitstreaming, you should have the DPS studio output formatting turned OFF.
That is a conversion. We need to start with this off to reduce the number of variables we are testing.

Output mode was set to none.

Quote from: bob on May 12, 2014, 04:02:10 pm

Now the default when sending a dsf file to a device is to format it in DoP.
This is why you are seeing DoP input, DoP output in the audiopath when you turn bitstreaming DSD on.

The device is supposed to play this through the PCM driver.

Comparing to Windows and Mac.
The Mac cannot play non-DoP DSD.
Windows can ONLY play it in ASIO mode, it appears to us this requires some special driver work.

Makes sense now, we don't have ASIO to send native DSD, so you're packing the file in DoP format.

Quote from: bob on May 12, 2014, 04:02:10 pm

We are curious as to why you cannot play the DoP format DSD on your device with output format turned off (and mixer disabled).

I have tested this before with Debian, and found this post describing exactly the same thing as I'm having here so I think I can safely rule out ArchLinux.

Still, I made some room on my NUC (my HTPC) to dual boot it with Debian. But its got safe boot and EUFI and whatnot so I need some time to figure out how to do this without killing Windows 8, this won't happen today or tomorrow.

bob · « **Reply #22 on:** May 13, 2014, 09:54:50 am »

Quote from: InflatableMouse on May 13, 2014, 12:47:42 am

Output mode was set to none.

Makes sense now, we don't have ASIO to send native DSD, so you're packing the file in DoP format.

I have tested this before with Debian, and found this post describing exactly the same thing as I'm having here so I think I can safely rule out ArchLinux.

Still, I made some room on my NUC (my HTPC) to dual boot it with Debian. But its got safe boot and EUFI and whatnot so I need some time to figure out how to do this without killing Windows 8, this won't happen today or tomorrow.

The bios on the NUC's we've been getting are ancient (15) and the current is 32. It will not boot debian linux on our NUC without updating the bios.

InflatableMouse · « **Reply #23 on:** May 13, 2014, 10:49:01 am »

Thanks for the heads up but I got a newer model than the one you're using there. Mine is a latest gen Haswell i5 (D54250WYK), mainly for the HD5000 to run madVR on decent settings.

INTERACT FORUM

Author Topic: DSD testing (Read 8752 times)