Re: RFC - Work on FreeBSD's Audio Stack

Hello Alexander,

Alexander Leidinger wrote:
> If you want to integrate some drivers:
> https://lists.freebsd.org/pipermail/freebsd-multimedia/2019-June/019719.html
> https://lists.freebsd.org/pipermail/freebsd-multimedia/2019-September/019907.html
> 
> No idea if they are good quality drivers or not, and if those cards are
> still available, but at least someone tried to support them it may be
> sensible to check if it makes sense to do something with them or not.

Because of time constraints, I really don't think this would be a wise
allocation of time, so for now I am not going to look into this, I can
note it down on a future TODO list however, if there's interest from
more people.

> The dsp deices are clonable due to the virtualisation and auto-mixing into
> the hardware in the kernel. To my understanding the midi devices are not
> clonable as there is no generic way we could mix several outputs from
> programs into one hardware channel.

Is there any other way we can achieve the functionality mentioned in the
proposal though (i.e opening the same MIDI device from more than 1
application at the same time)?
 
> > Other improvements to the kernel code include 1) better-syncing with the
> > 4Front OSSv4 API, 2) addressing open bug
> > reports, 3) making optimizations where possible.
> 
> 1) I mentored a student in the Google summer of code which resulted in what
> we have now in the OSSv4 API. Parts of this work was done as stubs, e.g.
> #ifdef OSSV4_EXPERIMENT
> static int dsp_oss_getlabel(struct pcm_channel *wrch, struct pcm_channel
> *rdch, oss_label_t *label);
> static int dsp_oss_setlabel(struct pcm_channel *wrch, struct pcm_channel
> *rdch, oss_label_t *label);
> static int dsp_oss_getsong(struct pcm_channel *wrch, struct pcm_channel
> *rdch, oss_longname_t *song);https://www.leidinger.net/FreeBSD/dox/dev_sound/html/
> static int dsp_oss_setsong(struct pcm_channel *wrch, struct pcm_channel
> *rdch, oss_longname_t *song);
> static int dsp_oss_setname(struct pcm_channel *wrch, struct pcm_channel
> *rdch, oss_longname_t *name);
> #endif
> and also dsp_oss_setchnorder().
> 
> Maybe you are interested to un-stub them.

Yeap.

> > Widely-used existing codebases that can benefit from oss(3) are virtual
> > oss and Mozilla’s cubeb oss audio framework,
> > which are also great sources of inspiration for features included in
> > oss(3).
> 
> VirtualOSS is now unmaintained (the author died). Maybe we want to adopt it
> into the base?

So, I am totally on board with this idea, in fact, taking over
maintenance of virtual_oss and porting it to base was one of the
project's initial goals, however I realized it might need considerable
effort to do so, due to the fact it uses external libraries (fftw and
libsamplerate IIRC), which, as I mentioned above, might not be the
wisest allocation of resources in this case, considering the scope of
the project is quite large already. My current plan is to work on the
existing deliverables, and if time allows, look into how virtual_oss can
be ported to base.
 
> > Bluetooth device management utility
> 
> Someone started with a bluetooth daemon a while ago. It sounds like this and
> your proposal share a common goal. No idea what the state of it is, but
> maybe you want to check it out:
> https://lists.freebsd.org/archives/freebsd-bluetooth/2022-August/000021.html

I am aware of this project and plan to use some of its ideas as
inspiration, although I find it to be quite overengineered in my humble
opinion.

> > Documentation
> > 
> Some parts of the kernel sound code contain docs written in doxygen syntax.
> A rendered version of it (if there is no error in the daily generation for
> -current) is available at
>     https://www.leidinger.net/FreeBSD/dox/dev_sound/html/
> and the corresponding TODO markup is rendered at
> https://www.leidinger.net/FreeBSD/dox/dev_sound/html/dd/da0/todo.html
> an example of the function docs (for dsp_oss_syncgroup()) is at
> https://www.leidinger.net/FreeBSD/dox/dev_sound/html/d5/d3b/dsp_8c.html#a304ece74c26d57a7df3ab5f104a3feff
> 
> It would be nice if changes to the kernel maintain/add to the doxygen
> markup.

That's a great idea. I've already been using this page to navigate
through the sound code more easily, so that's definitely something worth
adding to. We'll stay in touch for when the time comes.

Christos