Re: playback-only code in snd-dice?
Brought to you by:
aeb,
bencollins
From: Daniel R. <dro...@fu...> - 2014-10-22 22:34:29
|
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. 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. Thanks to everyone who has helped to provide such high-quality firewire sound drivers for Linux. -Daniel On Wed, Oct 22, 2014 at 2:32 PM, Stefan Richter <st...@s5...> wrote: > On Oct 22 Daniel Robbins wrote: >> I now have firewire audio working with 3.17.1. But I still have to >> hack the kernel sources to get this to work... the remaining problem >> with dice.c is the fact that it disables itself if it sees that the >> device has record capabilities, assuming you will use FFADO. > > With a little bit more patching than that, you could even modify the > driver to support capture: > https://github.com/takaswie/snd-firewire-improve . > (I haven't tested this myself yet.) > >> Well, guess what? I would just like my firewire audio to just work >> in-kernel without modifying source code. I request that you remove this >> artificial limitation of the driver. > > I too would be in favor of this limitation being lifted (unless > Sakamoto-san's work goes into the mainline sooner, of course), but with a > qualification; see below. > >> My Mytek DSD DAC is used for playback only, so just because a device >> advertises record capability doesn't actually mean it is a record >> device in practice. The module should load and function, and if the >> user doesn't want to use it, they can blacklist it. My opinion of >> course, but what good reason is there to have snd-dice *not* function >> without hacking source code when it could by default? > > For users of DICE devices for recording, it would currently be a regression > if the kernel prevented FFADO from accessing the device. There would be > two alternative solutions: Either recording users would need to add a > module blacklist rule on their systems. Or the playback-only driver > would be extended by a module parameter that tells it to bind to bidi > devices too, and that parameter would be off by default. With the > second approach, users who only require playback through their bidi device > would have to add a module parameter config on their systems, while users > who want to record do not need to reconfigure anything. > -- > Stefan Richter > -=====-====- =-=- =-==- > http://arcgraph.de/sr/ |