Re: [alsa-devel] RME Fireface alsa driver
Hi, (C.C.ed to alsa-devel)
At first, I apologize that ALSA fireface driver since Linux kernel v4.12 includes some bugs for its packet handling for PCM capture substream[1]. This bug can brings disorder of jackd process.
Furthermore, even if handling rx packets correctly, Fireface 400 cannot generate sounds because audio data frame is not picked up from isochronous packets to DSP[2].
I've already posted some patches to fix these bugs. The patches were already merged to ALSA upstream and they'll be going to mainline in next merge window for v4.21 kernel. They were also posted for stable kernel and later you can receive patched kernel image if you use any stable kernels.
If you'll test these patches in current your environment, please get recent code from my remote repository for backport to Linux v4.17 or later: https://github.com/takaswie/snd-firewire-improve
Your test will be great help to me because I've already left Fireface 400. (I rented it just for two weeks and I'll leave Fireface 800 soon as well.)
On Fri, 14 Dec 2018, thet wrote:
OK I have the FF400 set up now.
In my recent work for Fireface 800[3][4], I ensure that Fireface 800 can generate sounds even if the HOST LED turns on. This is the same experience with Fireface 400. Thus you can ignore whether the LED turn off or not.
What action should I take to create an error that is meaningful? .. when I start audacious from the terminal using the alsa output plugin and the FF400 selected I get:
Any GUI tools are not necessarily good for debugging. Please use 'aplay' insted, like:
$ aplay -v -D hw:Fireface400 -r 44100 -c 18 -f S32_LE /dev/urandom $ aplay -v -D hw:Fireface400 -r 88200 -c 14 -f S32_LE /dev/urandom $ aplay -v -D hw:Fireface400 -r 192000 -c 10 -f S32_LE /dev/urandom
In the above cases, I expect your unit can generate noisy sounds with the latest code of driver.
Anyway, I note you not to drop list address (alsa-devel@alsa-project.org) from CC list. It's valuable to share experiences of errors/failures because potentially they are good information for developers to seek bugs in software and be going to fix them.
[1] [alsa-devel] [PATCH 1/3] ALSA: firewire-lib: fix wrong handling payload_length as payload_quadlet http://mailman.alsa-project.org/pipermail/alsa-devel/2018-December/143147.ht... [2] [alsa-devel] [PATCH] ALSA: fireface: fix for state to fetch PCM frames http://mailman.alsa-project.org/pipermail/alsa-devel/2018-December/143150.ht... [3] [alsa-devel] [PATCH 0/8] ALSA: fireface: add support for Fireface 800 with MIDI functionality only http://mailman.alsa-project.org/pipermail/alsa-devel/2018-December/142826.ht... [4] [alsa-devel] [PATCH 0/5] ALSA: fireface: add support for Fireface 800 with streaming functionality http://mailman.alsa-project.org/pipermail/alsa-devel/2018-December/143154.ht...
Regards
Takashi Sakamoto
thank you! that seems like good work.
I am not confident to do the backport, but I will test when the kernel is available in a repo to install.
Or if you can send me a compiled kernel to test I can test it.
On 17/12/2018 14:16, Takashi Sakamoto wrote:
Hi, (C.C.ed to alsa-devel)
At first, I apologize that ALSA fireface driver since Linux kernel v4.12 includes some bugs for its packet handling for PCM capture substream[1]. This bug can brings disorder of jackd process.
Furthermore, even if handling rx packets correctly, Fireface 400 cannot generate sounds because audio data frame is not picked up from isochronous packets to DSP[2].
I've already posted some patches to fix these bugs. The patches were already merged to ALSA upstream and they'll be going to mainline in next merge window for v4.21 kernel. They were also posted for stable kernel and later you can receive patched kernel image if you use any stable kernels.
If you'll test these patches in current your environment, please get recent code from my remote repository for backport to Linux v4.17 or later: https://github.com/takaswie/snd-firewire-improve
Your test will be great help to me because I've already left Fireface 400. (I rented it just for two weeks and I'll leave Fireface 800 soon as well.)
On Fri, 14 Dec 2018, thet wrote:
OK I have the FF400 set up now.
In my recent work for Fireface 800[3][4], I ensure that Fireface 800 can generate sounds even if the HOST LED turns on. This is the same experience with Fireface 400. Thus you can ignore whether the LED turn off or not.
What action should I take to create an error that is meaningful? .. when I start audacious from the terminal using the alsa output plugin and the FF400 selected I get:
Any GUI tools are not necessarily good for debugging. Please use 'aplay' insted, like:
$ aplay -v -D hw:Fireface400 -r 44100 -c 18 -f S32_LE /dev/urandom $ aplay -v -D hw:Fireface400 -r 88200 -c 14 -f S32_LE /dev/urandom $ aplay -v -D hw:Fireface400 -r 192000 -c 10 -f S32_LE /dev/urandom
In the above cases, I expect your unit can generate noisy sounds with the latest code of driver.
Anyway, I note you not to drop list address (alsa-devel@alsa-project.org) from CC list. It's valuable to share experiences of errors/failures because potentially they are good information for developers to seek bugs in software and be going to fix them.
[1] [alsa-devel] [PATCH 1/3] ALSA: firewire-lib: fix wrong handling payload_length as payload_quadlet http://mailman.alsa-project.org/pipermail/alsa-devel/2018-December/143147.ht...
[2] [alsa-devel] [PATCH] ALSA: fireface: fix for state to fetch PCM frames http://mailman.alsa-project.org/pipermail/alsa-devel/2018-December/143150.ht...
[3] [alsa-devel] [PATCH 0/8] ALSA: fireface: add support for Fireface 800 with MIDI functionality only http://mailman.alsa-project.org/pipermail/alsa-devel/2018-December/142826.ht...
[4] [alsa-devel] [PATCH 0/5] ALSA: fireface: add support for Fireface 800 with streaming functionality http://mailman.alsa-project.org/pipermail/alsa-devel/2018-December/143154.ht...
Regards
Takashi Sakamoto
On Tue, Dec 18, 2018 at 11:38:47PM +0000, thet wrote:
I am not confident to do the backport, but I will test when the kernel is available in a repo to install.
Or if you can send me a compiled kernel to test I can test it.
I'm sorry but I have no interest in your system at all, thus I don't use my time for something of it. I'm a software developer, not your servant.
If you voluntarily wish to compile and install out-of-tree codes in my repository and test built driver modules, I can give you a short instruction for them. But in this case, it's better for you to read README[1] at first and foremost.
[1] https://github.com/takaswie/snd-firewire-improve/
Thanks
Takashi Sakamoto
I'm sorry if I inadvertently suggested something specific to me or my system. I did not think I was doing that.
Actually i was offering to help by testing. I'm sorry I don't have the skills to help in the way that would be most useful for you by compiling the kernel from source code - but that does not mean i am asking you to do something special for me. I could also help by lending my FF400 for a short time to a UK based developer if there is one.
I am NOT a software developer and I have very little knowledge of kernels or hardware level coding. I don't really have time to learn.
I shouldn't even be on this list - I only asked about the status of the FF400 driver here because there was no response on the alsa users list.
i will test the alsa driver for the FF400 when it becomes available in one of the kernels I use through the normal repos and ppas for those.
On 19/12/2018 04:22, Takashi Sakamoto wrote:
I'm sorry but I have no interest in your system at all, thus I don't use my time for something of it. I'm a software developer, not your servant.
Hi,
On Wed, Dec 19, 2018 at 02:51:29PM +0000, thet wrote:
I'm sorry if I inadvertently suggested something specific to me or my system. I did not think I was doing that.
Actually i was offering to help by testing. I'm sorry I don't have the skills to help in the way that would be most useful for you by compiling the kernel from source code - but that does not mean i am asking you to do something special for me. I could also help by lending my FF400 for a short time to a UK based developer if there is one.
I am NOT a software developer and I have very little knowledge of kernels or hardware level coding. I don't really have time to learn.
I shouldn't even be on this list - I only asked about the status of the FF400 driver here because there was no response on the alsa users list.
i will test the alsa driver for the FF400 when it becomes available in one of the kernels I use through the normal repos and ppas for those.
On 19/12/2018 04:22, Takashi Sakamoto wrote:
I'm sorry but I have no interest in your system at all, thus I don't use my time for something of it. I'm a software developer, not your servant.
Today fixes are queued to stable kernels; v4.20[1], v4.19[2], v4.14[3].
[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/comm... [2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/comm... [3] https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/comm...
Regards
Takashi Sakamoto
I notice that the RME fireface alsa driver snd-fireface now works a little since 4.19 I think
In earlier kernels 4.18 and below the midi worked on the FF400 but no audio and the FF800 was not supported at all.
now the midi works on both FF400 and FF800 and the audio works a little.
the kernel I am using is 5.0.0-7.1-liquorix-amd64 #1 ZEN SMP PREEMPT liquorix 5.0-6ubuntu1~bionic (2019-04-06) x86_64 x86_64 x86_64 GNU/Linux
(I am also happy to test with a different kernel but I am not able to compile it myself so it would need to be available in a repo.)
The audio however does not work correctly. It is unstable, sometimes it works for a while but other times it glitches or even becomes wildly distorted.
I am not a kernel developer at all - but I am willing to test and post logs if it helps - if anyone here can give me clear instructions about how to test.
Also - is it possible for a user to disable the audio part of the driver but still use the midi part?
This would allow me to use the audio with FFADO and the midi with alsa. FFADO doesn't support midi on these devices so it is great that alsa does - but running both at once can be tricky as the alsa driver does not let FFADO take over the device once it has it.
Can I suggest that maybe the audio and midi drivers for these devices could be made as separate kernel modules? Then if one part has problems it need not be loaded. I'm not sure if this is feasible but if it is it would allow more flexibility in how they are used.
thanks
Thet
Hi,
On Thu, Apr 18, 2019, at 06:01, thet wrote:
I notice that the RME fireface alsa driver snd-fireface now works a little since 4.19 I think
In earlier kernels 4.18 and below the midi worked on the FF400 but no audio and the FF800 was not supported at all.
FF400 support was firstly added to Linux v4.12, however the initial driver includes some bugs. Below fixes were already committed to stable kernels.
* fa9c98e4b975 ("ALSA: fireface: fix reference to wrong register for clock configuration")[1] * 3d16200a3e55 ("ALSA: fireface: fix for state to fetch PCM frames")[2]
If using Linux kernel v4.19.14 or later, or v4.14.92 or later, both of audio and midi work with FF400.
now the midi works on both FF400 and FF800 and the audio works a little.
the kernel I am using is 5.0.0-7.1-liquorix-amd64 #1 ZEN SMP PREEMPT liquorix 5.0-6ubuntu1~bionic (2019-04-06) x86_64 x86_64 x86_64 GNU/Linux
FF800 support was firstly added to Linux v5.0.
(I am also happy to test with a different kernel but I am not able to compile it myself so it would need to be available in a repo.)
The audio however does not work correctly. It is unstable, sometimes it works for a while but other times it glitches or even becomes wildly distorted.
Yes. I've reported this issue when posting the RFC patchset of this driver[3]. Furthermore, I experience the issue in all of supported models; FF400, FF800 and UCX.
I am not a kernel developer at all - but I am willing to test and post logs if it helps - if anyone here can give me clear instructions about how to test.
This issue belongs to knowledge about protocol used in transmission of data on IEEE 1394 bus, thus it's beyond to kernel development.
On RME Fireface series, unique protocol is used to transfer PCM frames and its presentation timing[4][5][6]. This is completely different from the standard protocol; IEC 61883-1/6. Therefore, thorough packet analysis is required, but nobody has achieved to clear it.
Also - is it possible for a user to disable the audio part of the driver but still use the midi part?
This would allow me to use the audio with FFADO and the midi with alsa. FFADO doesn't support midi on these devices so it is great that alsa does - but running both at once can be tricky as the alsa driver does not let FFADO take over the device once it has it.
I designed ALSA fireface driver with enough care for libffado, so you can use ALSA MIDI functionality and libffado packet streaming at the same time.
For details, please read commit logs relevant to ALSA fireface driver[7] I'll always write the logs with enough information about my commit, especially about the way to handle the target device, unclear points, impacts/requirements for userspace applications and so on.
Can I suggest that maybe the audio and midi drivers for these devices could be made as separate kernel modules? Then if one part has problems it need not be loaded. I'm not sure if this is feasible but if it is it would allow more flexibility in how they are used.
You seem to register one of the separated modules accounting for PCM feature to blacklist for kmod. I have a mixed feeling to this idea.
When ALSA firewire stack got a driver for devices which libffado also supports[8], an userspace API was introduced as well. This API is designed to disallow the kernel driver to start packet streaming. This feature is expected to intervene kernel drivers and userspace applications against resources of the packet streaming.
The application can disallow kernel drivers for it by a simple way (opening ALSA FwDep character device execute ioctl(2) with SNDRV_FIREWIRE_IOCTL_LOCK, then close).
I'll suggest you to encourage libffado developers (or yourself) to implement it because the cost to separate kernel module is not so cheap as you expected.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/sound... [2] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/sound... [3] https://mailman.alsa-project.org/pipermail/alsa-devel/2015-December/102261.h... [4] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/sound... [5] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/sound... [6] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/sound... [7] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/log/sound/fi... [8] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/sound... [9] https://github.com/takaswie/libhinawa/blob/master/src/snd_unit.c#L235
Regards
Takashi Sakamoto
participants (2)
-
Takashi Sakamoto -
thet