Thread: DICE: VIA firewire controller can't to > 48KHz
Brought to you by:
aeb,
bencollins
From: Daniel R. <dro...@fu...> - 2014-11-21 15:47:54
|
Hi Clemens, all: I recently set up a new system with a PCI Express firewire card. I am unable to get a PCM bitrate greater than 48KHz, and DSD/DOP does not function at all. <=48KHz PCM functions as expected. Kernel is 'vanilla' 3.17.3. I am using the following card: 01:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series Firewire Controller (prog-if 10 [OHCI]) Subsystem: VIA Technologies, Inc. VT6315 Series Firewire Controller Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at f0500000 (64-bit, non-prefetchable) [size=2K] I/O ports at e000 [size=256] Capabilities: [50] Power Management version 3 Capabilities: [80] MSI: Enable- Count=1/1 Maskable+ 64bit+ Capabilities: [98] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [130] Device Serial Number 00-90-21-ff-ff-00-00-0e Kernel driver in use: firewire_ohci Kernel modules: firewire_ohci This card is branded by NewEgg as Syba but the packaging says "IOCrest". This is the actual card: http://www.newegg.com/Product/Product.aspx?Item=N82E16815124138&cm_re=firewire_pci_express_card-_-15-124-138-_-Product Regards, Daniel |
From: Clemens L. <cl...@la...> - 2014-11-21 16:13:46
|
Daniel Robbins wrote: > I am unable to get a PCM bitrate greater than 48KHz What happens? Regards, Clemens |
From: Daniel R. <dro...@fu...> - 2014-11-21 16:19:15
|
For PCM, it seems that mpd (music program) is able to "see" that >48KHz is not supported, and resamples >48KHz PCM audio to 48KHz (for 96KHz, 192, etc.). For DOP, the DAC stays locked at the bitrate it was on previously (when switching from a PCM track, so either 44.1 or 48KHz). There is no audible output, but level meters show very low-level audio output (below -60db). I am able to pause this to zero the level meters. This seems similar to the behavior I saw when we had non-functioning dual-wire on my older system, except higher bitrate PCM did work just fine whereas in this case, the DAC is not put into anything higher than 48KHz. Regards, Daniel On Fri, Nov 21, 2014 at 9:13 AM, Clemens Ladisch <cl...@la...> wrote: > Daniel Robbins wrote: > > I am unable to get a PCM bitrate greater than 48KHz > > What happens? > > > Regards, > Clemens > |
From: Daniel R. <dro...@fu...> - 2014-12-03 19:07:46
|
Any more information I can provide on this? I now have two firewire cards with this VIA chip and they are unable to output >48KHz. -Daniel On Fri, Nov 21, 2014 at 9:19 AM, Daniel Robbins <dro...@fu...> wrote: > For PCM, it seems that mpd (music program) is able to "see" that >48KHz is > not supported, and resamples >48KHz PCM audio to 48KHz (for 96KHz, 192, > etc.). > > For DOP, the DAC stays locked at the bitrate it was on previously (when > switching from a PCM track, so either 44.1 or 48KHz). There is no audible > output, but level meters show very low-level audio output (below -60db). I > am able to pause this to zero the level meters. > > This seems similar to the behavior I saw when we had non-functioning > dual-wire on my older system, except higher bitrate PCM did work just fine > whereas in this case, the DAC is not put into anything higher than 48KHz. > > Regards, > > Daniel > > On Fri, Nov 21, 2014 at 9:13 AM, Clemens Ladisch <cl...@la...> > wrote: > >> Daniel Robbins wrote: >> > I am unable to get a PCM bitrate greater than 48KHz >> >> What happens? >> >> >> Regards, >> Clemens >> > > |
From: Clemens L. <cl...@la...> - 2014-12-08 13:03:37
|
Daniel Robbins wrote: > For PCM, it seems that mpd (music program) is able to "see" that > >48KHz is not supported, and resamples >48KHz PCM audio to 48KHz (for > 96KHz, 192, etc.). Does mpd actually use the "hw" device, and not "dmix" (or "default"), which would force everything to 48 kHz? Regards, Clemens |
From: Daniel R. <dro...@fu...> - 2014-12-08 16:42:12
|
On Mon, Dec 8, 2014 at 6:03 AM, Clemens Ladisch <cl...@la...> wrote: > Does mpd actually use the "hw" device, and not "dmix" (or "default"), > which would force everything to 48 kHz? I made sure it is using the "hw" device, and now it can do high bitrate PCM just fine, but it fails on DOP: Dec 08 16:35 : alsa_output: Failed to open "ALSA-firewire" [alsa]: Failed to configure DSD-over-PCM on ALSA device "hw:1,0" Regards, Daniel |
From: Clemens L. <cl...@la...> - 2014-12-08 18:30:39
|
Daniel Robbins wrote: > it can do high bitrate PCM just fine, but it fails on DOP: > > [alsa]: Failed to configure DSD-over-PCM on ALSA device "hw:1,0" This message means that the device does not support the S24 or S32 sample formats. However, FireWire devices definitively support S32. Please set log_level to verbose and check what mpd's alsa driver says then. Regards, Clemens |
From: Daniel R. <dro...@fu...> - 2014-12-09 23:45:34
|
On Mon, Dec 8, 2014 at 11:30 AM, Clemens Ladisch <cl...@la...> wrote: > This message means that the device does not support the S24 or S32 > sample formats. However, FireWire devices definitively support S32. > > Please set log_level to verbose and check what mpd's alsa driver > says then. It appears to be having problems with S32_LE: Dec 09 21:03 : output: closed plugin=alsa name="ALSA-firewire" Dec 09 21:03 : alsa_output: opened hw:1,0 type=HW Dec 09 21:03 : alsa_output: format=S32_LE (Signed 32 bit Little Endian) Dec 09 21:03 : alsa_output: buffer: size=896..1048576 time=5079..5944309 Dec 09 21:03 : alsa_output: period: size=896..1048576 time=5079..5944309 Dec 09 21:03 : alsa_output: default period_time = buffer_time/4 = 499954/4 = 124988 Dec 09 21:03 : alsa_output: buffer_size=88192 period_size=22048 Dec 09 21:03 : alsa_output: Failed to open "ALSA-firewire" [alsa]: Failed to configure DSD-over-PCM on ALSA device "hw:1,0" Dec 09 21:03 : output: Failed to open audio output Regards, Daniel |
From: Daniel R. <dro...@fu...> - 2014-12-09 23:56:31
|
On Tue, Dec 9, 2014 at 4:45 PM, Daniel Robbins <dro...@fu...> wrote: > > It appears to be having problems with S32_LE: > > Dec 09 21:03 : output: closed plugin=alsa name="ALSA-firewire" > Dec 09 21:03 : alsa_output: opened hw:1,0 type=HW I purchased a TI chipset PCI-E card to do more testing, and just reproduced the exact same test on the new machine. The TI card experiences the exact same issue. It can't do S32_LE. So it doesn't appear to be a VIA vs. TI issue. The old system that worked had a TI chip on a PCI (not PCI-E) card, and had a very similar setup. But apparently, there are enough differences in the kernel/other places for the TI PCI card to work, but the TI/VIA PCI-E cards to not work in the new system. Regards, Daniel |
From: Clemens L. <cl...@la...> - 2014-12-12 08:15:50
|
Daniel Robbins wrote: > It appears to be having problems with S32_LE: > > Dec 09 21:03 : output: closed plugin=alsa name="ALSA-firewire" > Dec 09 21:03 : alsa_output: opened hw:1,0 type=HW > Dec 09 21:03 : alsa_output: format=S32_LE (Signed 32 bit Little Endian) At this point, S32_LE is confirmed to be supported. > Dec 09 21:03 : alsa_output: buffer: size=896..1048576 time=5079..5944309 > Dec 09 21:03 : alsa_output: period: size=896..1048576 time=5079..5944309 > Dec 09 21:03 : alsa_output: default period_time = buffer_time/4 = 499954/4 = 124988 > Dec 09 21:03 : alsa_output: buffer_size=88192 period_size=22048 At this point, the hardware has been configured successfully. > Dec 09 21:03 : alsa_output: Failed to open "ALSA-firewire" [alsa]: Failed to configure DSD-over-PCM on ALSA device "hw:1,0" And now it aborts. The only explanation is that channels or sample_rate changed. Does "aplay -D hw:1 -f S32_LE -c 2 -r 176400 -t raw /dev/zero" work? Regards, Clemens |
From: Daniel R. <dro...@fu...> - 2014-12-12 19:20:20
|
On Fri, Dec 12, 2014 at 1:15 AM, Clemens Ladisch <cl...@la...> wrote: > Does "aplay -D hw:1 -f S32_LE -c 2 -r 176400 -t raw /dev/zero" work? Depends what you mean by "work". Here is the output: node ~ # aplay -D hw:1 -f S32_LE -c 2 -r 176400 -t raw /dev/zero Playing raw data '/dev/zero' : Signed 32 bit Little Endian, Rate 176400 Hz, Stereo aplay: set_params:1239: Channels count non available node ~ # Regards, Daniel |
From: Clemens L. <cl...@la...> - 2014-12-12 19:46:48
|
Daniel Robbins wrote: > On Fri, Dec 12, 2014 at 1:15 AM, Clemens Ladisch <cl...@la...> wrote: >> Does "aplay -D hw:1 -f S32_LE -c 2 -r 176400 -t raw /dev/zero" work? > > Depends what you mean by "work". Here is the output: > > node ~ # aplay -D hw:1 -f S32_LE -c 2 -r 176400 -t raw /dev/zero > Playing raw data '/dev/zero' : Signed 32 bit Little Endian, Rate 176400 Hz, Stereo > aplay: set_params:1239: Channels count non available And you DoP stuff uses two channels? That would be the problem then. Try using plughw:1 instead. Regards, Clemens |
From: Daniel R. <dro...@fu...> - 2014-12-12 20:33:13
|
On Fri, Dec 12, 2014 at 12:46 PM, Clemens Ladisch <cl...@la...> wrote: > And you DoP stuff uses two channels? That would be the problem then. Yes, it's a two-channel DAC. This "works": node ~ # aplay -D plughw:1 -f S32_LE -c 2 -r 176400 -t raw /dev/zero Playing raw data '/dev/zero' : Signed 32 bit Little Endian, Rate 176400 Hz, Stereo ^CAborted by signal Interrupt... aplay: pcm_write:1939: write error: Interrupted system call node ~ # This appears to be the relevant code in mpd relating to setting up alsa for DOP. It appears that it is trying to use S24_P32 rather than S32 -- could this be the issue? alsa_setup_dop(AlsaOutput *ad, const AudioFormat audio_format, bool *shift8_r, bool *packed_r, bool *reverse_endian_r, Error &error) { assert(ad->dop); assert(audio_format.format == SampleFormat::DSD); /* pass 24 bit to alsa_setup() */ AudioFormat dop_format = audio_format; dop_format.format = SampleFormat::S24_P32; dop_format.sample_rate /= 2; const AudioFormat check = dop_format; if (!alsa_setup(ad, dop_format, packed_r, reverse_endian_r, error)) return false; /* if the device allows only 32 bit, shift all DoP samples left by 8 bit and leave the lower 8 bit cleared; the DSD-over-USB documentation does not specify whether this is legal, but there is anecdotical evidence that this is possible (and the only option for some devices) */ *shift8_r = dop_format.format == SampleFormat::S32; if (dop_format.format == SampleFormat::S32) dop_format.format = SampleFormat::S24_P32; if (dop_format != check) { /* no bit-perfect playback, which is required for DSD over USB */ error.Format(alsa_output_domain, "Failed to configure DSD-over-PCM on ALSA device \"%s\"", alsa_device(ad)); delete[] ad->silence; return false; } return true; } Regards, Daniel |
From: Clemens L. <cl...@la...> - 2014-12-12 21:54:15
|
Daniel Robbins wrote: > On Fri, Dec 12, 2014 at 12:46 PM, Clemens Ladisch <cl...@la...> wrote: >> And you DoP stuff uses two channels? That would be the problem then. > > Yes, it's a two-channel DAC. This "works": > > # aplay -D plughw:1 -f S32_LE -c 2 -r 176400 -t raw /dev/zero > Playing raw data '/dev/zero' : Signed 32 bit Little Endian, Rate 176400 Hz, Stereo > > This appears to be the relevant code in mpd relating to setting up > alsa for DOP. It appears that it is trying to use S24_P32 rather than > S32 -- could this be the issue? No, S32 is explicitly allowed. The issue is that the number of channels changes. What are the contents of /proc/asound/card1/dice? Regards, Clemens |
From: Daniel R. <dro...@fu...> - 2014-12-12 22:02:19
|
On Fri, Dec 12, 2014 at 2:53 PM, Clemens Ladisch <cl...@la...> wrote: > What are the contents of /proc/asound/card1/dice? After attempting to play a DOP file (was previously successfully playing a 24/96 PCM file), it looks like this: node ~ # cat /proc/asound/card1/dice sections: global: offset 10, size 95 tx: offset 105, size 142 rx: offset 247, size 282 ext_sync: offset 529, size 4 unused2: offset 0, size 0 global: owner: ffc1:000100000000 notification: 00000050 nick name: Stereo192-DSD DAC clock select: arx1 176400 enable: 0 status: unlocked 96000 ext status: 00000000 sample rate: 96000 version: 1.0.12.0 clock caps: 44100 48000 88200 96000 176400 192000 aes2 aes3 aes4 adat wc arx1 clock source names: Unused\AES\TOSLINK\SPDIF\Unused\ADAT\Unused\Stereo192DAC\Unused\Unused\Unused\Unused\Unused\\ tx 0: iso channel: -1 audio channels: 8 midi ports: 0 speed: S400 names: AES L\AES R\TOSLINK L\TOSLINK R\SPDIF L\SPDIF R\ADAT0\ADAT1\\ ac3 caps: 00000000 ac3 enable: 00000000 rx 0: iso channel: -1 sequence start: 0 audio channels: 4 midi ports: 0 names: ANALOG L\ANALOG R\DSD1281\DSD1282\\ ac3 caps: 00000000 ac3 enable: 00000000 ext status: clock source: arx1 locked: 1 rate: 96000 adat user data: - Regards, Daniel |
From: Clemens L. <cl...@la...> - 2014-12-18 14:13:59
|
(sorry for the delay) Daniel Robbins wrote: > On Fri, Dec 12, 2014 at 2:53 PM, Clemens Ladisch <cl...@la...> wrote: >> What are the contents of /proc/asound/card1/dice? > > After attempting to play a DOP file (was previously successfully > playing a 24/96 PCM file), it looks like this: > > # cat /proc/asound/card1/dice > ... > clock select: arx1 176400 The device was told to synchronize to the stream from the PC, ... > status: unlocked 96000 ... but no stream was actually sent, so it is still at 96 kHz. > rx 0: > audio channels: 4 > names: ANALOG L\ANALOG R\DSD1281\DSD1282\\ At 96 kHz (and 88.2 kHz), it wants exactly four channels. And these channel names look somewhat suspicious. Try playing DSD to the following device, which routes its two channels to the last two channels of the device: pcm.last2 { type route slave.pcm "hw:1" ttable [ [ 0 0 1 0 ] [ 0 0 0 1 ] ] } The following would duplicate the channels to both pairs, which, in theory, should then work with both PCM and DSD: pcm.dup2 { type route slave.pcm "hw:1" ttable [ [ 1 0 1 0 ] [ 0 1 0 1 ] ] } Regards, Clemens |
From: Daniel R. <dro...@fu...> - 2014-12-18 19:59:25
|
On Thu, Dec 18, 2014 at 7:13 AM, Clemens Ladisch <cl...@la...> wrote: > The following would duplicate the channels to both pairs, which, in > theory, should then work with both PCM and DSD: > > pcm.dup2 { > type route > slave.pcm "hw:1" > ttable [ > [ 1 0 1 0 ] > [ 0 1 0 1 ] > ] > } The first snippet, when added to /root/.asoundrc, causes aplay -L to fail with: *** Error in `aplay': free(): invalid pointer: 0x000000000191a7b0 *** I am not sure how to use these devices with mpd for testing. Let me know what to do. -Daniel |