Re: playback-only code in snd-dice?
Brought to you by:
aeb,
bencollins
From: Stefan R. <st...@s5...> - 2014-10-23 07:54:20
|
On Oct 22 Daniel Robbins wrote: > I consider audio playback a more general function of the kernel that > is used much more often and something that should "just work". For > finding the best solution for Linux users, it is often a good idea to > consider potential use cases. So let's look at both: > > If you are doing audio recording, you are performing additional setup > (including recording app, drivers, microphones) and blacklisting a > module as part of this already more involved process is not > unreasonable. You are not likely to be inconvenienced significantly by > performing this step as it is a small part of a larger and more > ambitious goal. It requires a slight change in user behavior but is > not what I would consider a regression. (We did in fact already inconvenience many FFADO users when we replaced the ieee1394 driver family by the firewire driver family, and discovered several driver bugs/ libraw1394 bugs/ previously hidden hardware quirks that had to be resolved. And we will somewhat inconvenience FFADO users again, but hopefully create less trouble than before, while Sakamoto-san's bidirectional FireWire ALSA drivers are being merged into the mainline kernel.) > Now consider the person using dice just for playback, maybe just to > listen to music through their stereo with their fancy new DAC, and > hoping to use Linux, but with access to maybe Windows or MacOS > systems, so they are not willing to invest a ton of time in making > this work on Linux (I am more the exception than the rule.) If they > are using a pre-built kernel, they are currently stuck with no audio. > Not a good situation. Specifying a kernel boot option for audio > playback to work requires an additional step that most users will not > perform since they will not be aware that it is required. They will > just not have audio, and will not look at the kernel sources to see > why, and think it is broken. So they will abandon Linux for streaming > music to their DAC. Also not a good situation. > > So, I think it's clear what option provides the optimal user > experience that is most likely to allow people to benefit from Linux > support for this hardware. I consider the current behavior to be a > regression in _behavior_ for a module, which is almost always: "if I > am 'modprobe'd, and I find a device that I support, then I will > function as expected with no additional kernel-related configuration > options.' This is the norm that users expect. So when there is > deviation from this norm, that is something that is more of a true > regression, in my opinon. You are raising valid points; on the other hand consider this: - kernels 3.12 and older: - support bidirectional DICE devices via FFADO out of the box (the limitation to bidi is FFADO's, not the kernel's) - do not support support DICE via ALSA - kernels 3.13...3.18: - still support bidi DICE via FFADO out of the box - newly support unidi DICE via ALSA out of the box - still do not support bidi DICE via ALSA So there is currently a other-OS-to-Linux regression, but no Linux-to-Linux regression. > Thanks to everyone who has helped to provide such high-quality > firewire sound drivers for Linux. > > -Daniel -- Stefan Richter -=====-====- =-=- =-=== http://arcgraph.de/sr/ |