Hello!
Did somebody here manage to use the Analog Heat +FX Class Compliant mode (selected under Settings > System > USB Config) as a sound card for either Linux or Android devices?
I have no problem using other interfaces in CC mode, just this one.
In Linux, the device is detected but the audio plays several times too slow and is distorted, as mentioned here.
Shall I contact Elektron support? I guess a Linux issue would be discarded but maybe Android?
Thanks for your help!
Welcome to Elektronauts, @mateba.
Probably this post (or thread) should be merged with the thread you linked. Somebody wrote there recently and I wanted to give it a try again. (I reported there the the class complaint mode doesn’t seem to work with my Digitakt either.)
Anyway., these are my current findings.
Recording just works. The resulting output file of this command can be opened with other tools and played thru other audio interfaces with no problem at all. The sample format is S32_LE as it is the only format natively supported.
$ arecord -D hw:CARD=Digitakt,DEV=0 -f S32_LE -c 2 -r 48000 --dump-hw-params sample.wav
Recording WAVE 'sample.wav' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo
HW Params of device "hw:CARD=Digitakt,DEV=0":
--------------------
ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT: S32_LE
SUBFORMAT: STD
SAMPLE_BITS: 32
FRAME_BITS: 64
CHANNELS: 2
RATE: 48000
PERIOD_TIME: (166 1000000]
PERIOD_SIZE: [8 48000]
PERIOD_BYTES: [64 384000]
PERIODS: [2 1024]
BUFFER_TIME: (333 2000000]
BUFFER_SIZE: [16 96000]
BUFFER_BYTES: [128 768000]
TICK_TIME: ALL
--------------------
^CAborted by signal Interrupt...
$ sox --i sample.wav
Input File : 'sample.wav'
Channels : 2
Sample Rate : 48000
Precision : 32-bit
Duration : 00:00:05.50 = 264025 samples ~ 412.539 CDDA sectors
File Size : 2.11M
Bit Rate : 3.07M
Sample Encoding: 32-bit Signed Integer PCM
But this command produces a distorted and much slower audio .
$ time aplay -D hw:CARD=Digitakt,DEV=0 -f S32_LE -c 2 -r 48000 --dump-hw-params sample.wav
Playing WAVE 'sample.wav' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo
HW Params of device "hw:CARD=Digitakt,DEV=0":
--------------------
ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT: S32_LE
SUBFORMAT: STD
SAMPLE_BITS: 32
FRAME_BITS: 64
CHANNELS: 2
RATE: 48000
PERIOD_TIME: (166 1000000]
PERIOD_SIZE: [8 48000]
PERIOD_BYTES: [64 384000]
PERIODS: [2 1024]
BUFFER_TIME: (333 2000000]
BUFFER_SIZE: [16 96000]
BUFFER_BYTES: [128 768000]
TICK_TIME: ALL
--------------------
real 0m15.020s
user 0m0.009s
sys 0m0.000s
By looking at the output from sox and time, the resulting audio is played around 2.7 times slower. Different tests give the same ratio.
Does arecord work for you? Can you reproduce the same behaviour? You can find your device with aplay -L.
Edit: Fix commands.
Hey @DG2,
First of all thanks for your answer. I considered posting in the other thread but didn’t want to bump a year old thread. We could definitely merge them if such a thing is possible, I’m not familiar with this platform.
I can reproduce and confirm everything you say.
Recording works perfectly (although a bit quiet but that might have been a mistake of mine), and playback produces the garbled audio we mentioned.
I tried many different settings and sound servers, eliminating potential causes until Alsa and snd_usb_audio remain. What seems weird to me is the sample format. This interface is supposed to work with 24bit audio if I’m not mistaken, but attempts to use (successfully upon recording) 32bit?! That’s what S32_LE is (32 bit little endian) right? But that might not necessarily be tied with the actual bit depth, maybe it’s just a “container” format. I’m not sure 
By the way, Overwitch works great, before anybody mentions it. It’s a beautiful little piece of software but not what I’m looking for here!
I’ll keep digging for some hints but I’m afraid Class Compliance is a bit too vague and some devices comply less than others 
Same thing here. Looks like s a firmware-USB-module thing.
I was suspicious about the bitdepth too but if recording works and produces 32 bit little endian samples, why is the playback not working if ALSA reports the same format? I think, as you said, in this case transport is 32 bits but the useful payload is only 24 bits. Also, as the playback ratio is 2.7, the numbers don’t match and the issue should be somewhere else.
I’ll try to dig deeper on the module parameters.
After reading @joanq’s post on the other thread, I decided to try my Digitakt with my laptop and… it just worked. It’s a 6 year old low-spec Lenovo laptop. (I’d say I tried this before but…)
So I came back to my computer and unplugged every USB device but the keyboard and mouse. Then I connected my Digitakt and… it just worked.
Later I tested it with different USB ports and the noise was there on some of them.
I decided to run some tests and this is what I discovered.
The issue appear always with the bus 001. Plugging or unplugging other devices made no difference. Using a hub makes no difference.
When the Digitakt is plugged into other USB busses, seems to work.
OK
$ lsusb | grep Digitakt
Bus 003 Device 007: ID 1935:102c Elektron Music Machines Digitakt Audio/MIDI
$ lsusb -t
[...]
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
|__ Port 4: Dev 7, If 0, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 4: Dev 7, If 1, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 4: Dev 7, If 2, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 4: Dev 7, If 3, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 4: Dev 7, If 4, Class=Audio, Driver=snd-usb-audio, 480M
[...]
OK
$ lsusb | grep Digitakt
Bus 003 Device 012: ID 1935:102c Elektron Music Machines Digitakt Audio/MIDI
$ lsusb -t
[...]
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
|__ Port 4: Dev 8, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 4: Dev 10, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 3: Dev 12, If 0, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 3: Dev 12, If 1, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 3: Dev 12, If 2, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 3: Dev 12, If 3, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 3: Dev 12, If 4, Class=Audio, Driver=snd-usb-audio, 480M
[...]
ERROR
$ lsusb | grep Digitakt
Bus 001 Device 028: ID 1935:102c Elektron Music Machines Digitakt Audio/MIDI
$ lsusb -t
[...]
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 480M
[...]
|__ Port 2: Dev 25, If 0, Class=Hub, Driver=hub/4p, 480M
[...]
|__ Port 4: Dev 27, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 3: Dev 28, If 3, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 3: Dev 28, If 1, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 3: Dev 28, If 4, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 3: Dev 28, If 2, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 3: Dev 28, If 0, Class=Audio, Driver=snd-usb-audio, 480M
[...]
ERROR
$ lsusb | grep Digitakt
Bus 001 Device 042: ID 1935:102c Elektron Music Machines Digitakt Audio/MIDI
$ lsusb -t
[...]
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 480M
|__ Port 2: Dev 42, If 4, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 2: Dev 42, If 2, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 2: Dev 42, If 0, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 2: Dev 42, If 3, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 2: Dev 42, If 1, Class=Audio, Driver=snd-usb-audio, 480M
[...]
Notice the Digitakt USB interfaces appear unordered over bus 001.
It happens that the bus 001 is a 10 port hub, as reported in the field Driver and there are a lot of internal devices connected to it. I coud run more tests to try to find the root cause but it’s probably worthless.
So, let’s check what other devices are on the bus we connect our Elektron machines or if there is a USB bandwith issue and hope for the computer to have more than one root hub in case of problems.
@mateba, can you try with different USB ports?
We’re definitely getting there.
Good news: the interface actually works perfectly out-of-the-box on my Linux laptop.
Bad news: I tried every damn port of my desktop PC to no avail (actually I tried this before the original post, and tried again today).
I will attempt bios/kernel USB power-saving options tweaks and such… I think there’s also a parameter in the snd_usb_audio kernel driver to control the order of devices, I used to use it back in the days.
Thank you so much for reporting! I’ll update with some new info if I happen to have some.
Some observations:
lsusb output only has root_hubs
autoclock option of the kernel driverdelayed_register kernel driver option, nothing it my case but it might help youRegarding the latter, this option helps dealing with a data race registering the different streams of a same devide out-of-order.
Given you have the Digitakt USB vendor and product IDs:
Bus 003 Device 003: ID 1935:1053 Elektron Music Machines Elektron Analog Heat +FX
(here 1935 and 1053 for AHFX in my own lsusb output), I belive you could try:
options snd_usb_audio delayed_register=<vendor><product>:0,<vendor><product>:1,<vendor><product>:2,<vendor><product>:3,<vendor><product>:4
(note, IDs are concatenated in a single string: 19351053) in /etc/modprobe.d/snd_usb_audio.conf, reboot, and be able to plug it in any port. They should be in order. This configuration should wait for all streams to be probed before registering the device in the kernel.