Hi all,
Sometime in 2016, I believe with kernel ~4.6, my DAC started having weird behaviour. I found some mails about heavy firewire/DICE dev at the time so I sticked with 4.4 LTS for a while. I decided to do some proper research now and found out some details which hopefully will help solving the problem.
The hardware, problem is with DAC only: https://www.siig.com/it-products/firewire/firewire-400/pcie/dp-firewire-2-po... https://mytekdigital.com/hifi/products/stereo-192dsd-dac/ https://us.focusrite.com/firewire-audio-interfaces/saffire-pro-24
The Saffire works perfectly for all modules I tried. I believe my DAC's firmware may have some quirks with control/notification messages.
Behaviour comparison --------------------
Old modules (2eb65d67afbf9364b525b657f1475d1a2cbc27de): * Playback is instant, but DAC very rarely misses the lock. Need to restart the stream (stop, play MPD or restart jack) in that case. DAC's display still displays the samplerate change correctly, so probably firmware inconsistency. * Songs with different sample rate (e.g. 44100 -> 96000) switch instantly, unless DAC misses lock like above. DAC's display updates sample rate in 1-5 sec or so. * Sound itself is perfect, no cracks, pops or other issues. * Stop ALSA stream and DAC will indicate "No Lock", but procfs says locked. * dmesg is silent about firewire/dice/dac.
New modules (4.1.1.12 and 4.13): * Takes ~2 sec before playback starts, but always works. * When MPD changes music track to track with different format it will always hang ~2 sec and fail to change format anyway. * Sound has very consistent popping in it. Very noticeable on higher frequencies, some timing issue? Besides that no other issues. * Power cycle the DAC and it will be "unlocked". After that the first stream opened will perma-lock the format. Changing to other frequency will not work. * Stop ALSA stream and DAC will indicate "No Lock", but procfs says locked. * dmesg shows only: "snd_dice fw1.0: Invalid CIP header for AMDTP: 00000000:00000000" probably when it's trying to change frequency. No other messages.
I attached /proc/asound/DAC/dice output for old and new when idle, 44100 and 96000. global/notification and sample/lock change but that's basically it.
Module details --------------
To test modules on my current kernel, which is 4.11.12-1-rt13-rt, I git checkout desired version of /sound/firewire and make those modules. After that I insmod snd-firewire-lib and snd-dice.
The "old" modules refer to: 2eb65d67afbf9364b525b657f1475d1a2cbc27de ALSA: dice: expand timeout to wait for Dice notification
These work like kernel ~4.4 did on the new kernel, just needed to include <linux/sched/signal.h> to get it to compile.
New modules are as shipped as in kernel 4.11.12, might contain realtime patches. Also tried with mainline kernel 4.13's modules with same results.
The commit that breaks it for my DAC is the one directly after "old" when it comes to the DICE module: 0d5ee195b1091e6ebcc121c091ce8646e95a48b6 ALSA: dice: limit to current sampling transfer frequency
I don't notice any difference between the commit that "breaks" and current stable (4.13) when it comes to behaviour.
Suspected cause ---------------
I haven't read too much of the source code and all the development over time, so this is just a guess.
Before the module would probably just send the audio stream and hope it works whereas the newer versions try to do it properly, perhaps violating some standard.
The fact that according to procfs DAC's status is locked even when not playing might be why the current module will refuse to play at any different frequency. At least, that is what I think the description of 0d5ee195b1091e6ebcc121c091ce8646e95a48b6 is describing.
So probably some quirk in my DAC's firmware is causing this. I remember that the Windows drivers always locked even without playback. Changing frequency from the driver software caused DAC display to update instantly with the lock changing shortly after. Though I believe Focusrite's software did the same thing for the mic interface.
lspci -vv of my firewire card -----------------------------
Doubt this is related, but just in case. 03:00.0 FireWire (IEEE 1394): Texas Instruments XIO2200A IEEE-1394a-2000 Controller (PHY/Link) (rev 01) (prog-if 10 [OHCI]) Subsystem: AFAVLAB Technology Inc Device 0000 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 32 (500ns min, 1000ns max), Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 24 Region 0: Memory at fb704000 (32-bit, non-prefetchable) [size=2K] Region 1: Memory at fb700000 (32-bit, non-prefetchable) [size=16K] Capabilities: [44] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+ Kernel driver in use: firewire_ohci Kernel modules: firewire_ohci
P.S. Seems my DAC has dedicated stereo channels for DSD128 (probably also for DSD64) besides the PCM stereo channels. Any idea if/how that may work?
Melvin Vermeeren.