[alsa-devel] Can't get capturing from RME Hammerfall MADI card to work: sound loops & silcence
Hi,
I'm trying to capture audio from an RME Hammerfall MADI card (PCI ID 10ee:3fc6). The setup previously worked fine on Windows, so I'm currently assuming that the card and the input signal is OK.
I wrote a very simple ALSA-application that simply opens the device, sets the access format to NONINTERLEAVED (which seems to be the only option the card likes), selects 32bit sampling (although the audio is 24bit, ALSA rejects this option), 48kHz sampling and 64 channels (also, the only option the card accepts). Next, it loops with snd_pcm_readn() to get 100ms worth of audio, and dumps channel 10 to file. (Full source in attachement)
The result is strange for various reasons:
* The second half of every buffer returned by snd_pcm_readn() is always zero's.
* The call seems to return way to fast: I would expect to get 48000 frames/second, but judging from the timing of the snd_pcm_readn() call, it's more like 1536000 frames/second (i.e. 32 fold faster).
* When playing back the resulting file, I do recognize some music, but it sounds like it's the same part over and over again. Also, restarting the capture program minutes later, returns the same (at least as far as my ears & brain can recall) fragment of audio.
What am I doing wrong here? (Samples of the PCM-file are available upon request)
I've also tried a related test with `arecord`, with similar but different results:
* The audio was also interspersed with silence
* The capture duration did not match the requested '-d' option: the recording was a factor of 2 shorter than requested.
* There was more audio in the recording: if I manually cut out the silent parts, the audio sounded reasonable.
What am I missing here?
Is this the right place to ask? Or should this go to the RME forum?
Thanks in advance, Niels
Hi Niels,
Similar issues here, but can add it all seems to work absolutely fine with alsa 1.0.15, but fails with 1.0.18+. Alsamixer must be used to setup the card and Madi. 96k sampling also works if you set the madi into double-speed mode (on the older alsa). Can't compile 1.0.15 with later kernels unfortunately; some hooks seem to have changed !
Got no reply on rme Linux forum. On 27 Sep 2013 16:09, "Niels Laukens" niels.laukens@innovatie.vrt.be wrote:
Hi,
I'm trying to capture audio from an RME Hammerfall MADI card (PCI ID 10ee:3fc6). The setup previously worked fine on Windows, so I'm currently assuming that the card and the input signal is OK.
I wrote a very simple ALSA-application that simply opens the device, sets the access format to NONINTERLEAVED (which seems to be the only option the card likes), selects 32bit sampling (although the audio is 24bit, ALSA rejects this option), 48kHz sampling and 64 channels (also, the only option the card accepts). Next, it loops with snd_pcm_readn() to get 100ms worth of audio, and dumps channel 10 to file. (Full source in attachement)
The result is strange for various reasons:
- The second half of every buffer returned by snd_pcm_readn() is always
zero's.
- The call seems to return way to fast: I would expect to get 48000
frames/second, but judging from the timing of the snd_pcm_readn() call, it's more like 1536000 frames/second (i.e. 32 fold faster).
- When playing back the resulting file, I do recognize some music, but it
sounds like it's the same part over and over again. Also, restarting the capture program minutes later, returns the same (at least as far as my ears & brain can recall) fragment of audio.
What am I doing wrong here? (Samples of the PCM-file are available upon request)
I've also tried a related test with `arecord`, with similar but different results:
The audio was also interspersed with silence
The capture duration did not match the requested '-d' option: the
recording was a factor of 2 shorter than requested.
- There was more audio in the recording: if I manually cut out the silent
parts, the audio sounded reasonable.
What am I missing here?
Is this the right place to ask? Or should this go to the RME forum?
Thanks in advance, Niels
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
bruce wrote:
On 27 Sep 2013 16:09, "Niels Laukens" wrote:
I've also tried a related test with `arecord`, with similar but different results:
The audio was also interspersed with silence
The capture duration did not match the requested '-d' option: the
recording was a factor of 2 shorter than requested.
Similar issues here, but can add it all seems to work absolutely fine with alsa 1.0.15, but fails with 1.0.18+.
This sound like some change in the driver introduced a bug.
Regards, Clmeens
Clemens,
Similar issues here, but can add it all seems to work absolutely fine with alsa 1.0.15, but fails with 1.0.18+.
This sound like some change in the driver introduced a bug.
the driver works fine with versions up to 1.0.27. I have the card running on a daily base with current kernel versions.
Flo
On 09/27/2013 09:47 AM, Florian Faber wrote:
Clemens,
Similar issues here, but can add it all seems to work absolutely fine with alsa 1.0.15, but fails with 1.0.18+.
This sound like some change in the driver introduced a bug.
the driver works fine with versions up to 1.0.27. I have the card running on a daily base with current kernel versions.
same here, although mine is a bit older (lspci says rev d2). current 3.10.x and 3.11 kernels, alsa at 1.0.26.
niels, pretty much everyone who uses such hardware on linux will be running jack. can i suggest you run a brief check with jack, and then maybe look at its backend implementation to find out where stuff goes wrong?
On 27/09/2013 5:47 PM, Florian Faber wrote:
Clemens,
Similar issues here, but can add it all seems to work absolutely fine with alsa 1.0.15, but fails with 1.0.18+.
This sound like some change in the driver introduced a bug.
the driver works fine with versions up to 1.0.27. I have the card running on a daily base with current kernel versions.
Hi Flo (or driver developers),
I cannot get our card to work with alsa 1.0.27 (or 1.0.18), but it does work fine with 1.0.15. I'm trying to work out what could be different from my setup to yours. I have tried different PCs, different Linux distributions and two different HDSP cards. I'm using a HDSPe MADI Rev1.1 loaded with the latest firmware. Is yours the same ?
May I send you a particular application to attempt running on your system with 1.0.27 and see if it works ?
*Note* I can use all parts of 1.0.27 (eg, lib, alsamixer, aplay) /except/ for the Hammerfall driver (remains at 1.0.15) and it still works for me. I cannot install the new driver under an older kernel due to incompatibilities, but trying 1.0.18 or 1.0.27 (including later driver) with a newer kernel fails.
I thought if I could somehow get the 1.0.15 hammerfall driver working with a new kernel (help ??) I could then somehow step through the subsequent changes made to the driver one by one till it breaks. This approach could take some considerable time, so any pointers as to how to do this would be much appreciated ! I do not profess to know much about alsa driver development, or how to even access the (svn ?) revision steps, but this might be the only way to work out what is happening here.
Cheers, Bruce
PS: I will also ask the Hammerfall Linux forum, but that seems a bit inactive now.
Flo
participants (6)
-
bruce -
Bruce -
Clemens Ladisch -
Florian Faber -
Jörn Nettingsmeier -
Niels Laukens