Re: Re: [Development report #7] Audio Stack Improvements

On Fri, Mar 15, 2024 at 06:00:16PM +0100, Christos Margiolis wrote:
> Hello Mark,
> 
> Mark Johnston wrote:
> > > Behavior changes:
> > > - Only one /dev/dspX device is exposed, as opposed to the current
> > >   /dev/dspX.[X]X devices created by the snd_clone mechanism. The
> > >   user/application now only needs to access the device through /dev/dspX
> > >   or /dev/dsp and sound(4) will take care of all necessary audio
> > >   routing.
> > 
> > Does this represent a backward compatibility break?  That is, will
> > applications need any modification when running on a patched kernel?
> 
> Applications are meant to open an audio device through /dev/dsp (if
> hw.snd.basename_clone is enabled), or through /dev/dspX, so the vast
> majority of applications should work with no problems.
> 
> Applications that open a device through /dev/dspX.[X]X will break with
> this patch. However, opening a device like this is discouraged anyway,
> according to the sound(4) man page (see FILES section):

To your knowledge, do any popular applications actually do this?  A
comment in the man page isn't very important if applications end up
ignoring it. :)

If needed, would it be a lot of work to provide backward compatibility?

> 	[...]
> 	/dev/dsp%d.p%d       Playback channel.
> 	/dev/dsp%d.r%d       Record channel.
> 	/dev/dsp%d.vp%d      Virtual playback channel.
> 	/dev/dsp%d.vr%d      Virtual recording channel.
> 	[...]
> 
> 	The above device nodes are only created on demand through the
> 	dynamic devfs(5) clone handler.  Users are strongly discouraged
> 	to access them directly.  For specific sound card access, please
> 	instead use /dev/dsp or /dev/dsp%d.
> 
> The patch basically does the same thing -- the output of /dev/sndstat
> remains the same -- but without creating these device nodes.
> 
> Christos