Re: [Development report #7] Audio Stack Improvements

On Saturday, March 16, 2024 3:38:01 AM CET Mark Johnston wrote:
> 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. :)

Is it even possible to open pcm devices through /dev/dspX.Y currently?
I remember that I stumbled upon this when I developed the Jack backend and it 
wasn't possible to open /dev/dspX.Y, I had to use /dev/dspX. Just checked and 
that still seems to be the case on 14.0-RELEASE.
Unless I missed something, I'd conclude that it's not used in ports :-)

Non-clone aliases like /dev/dsp_mmap seem to work though, never actually seen 
them in use but I think we should preserve them as part of OSSv4 
compatibility.

Florian