Re: RFC - Work on FreeBSD's Audio Stack

Am 2023-12-15 00:34, schrieb Christos Margiolis:
> Hello Alexander,
> 
> Alexander Leidinger wrote:

>> 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)?

Theoretically I could imagine that we could map MIDI channels to FreeBSD 
MIDI devices (e.g. midi0 sees only channel X and midi1 sees only channel 
Y, so program A could react only to messages on channel X and doesn't 
see channel Y, and program B can only send to channel Y). How much of a 
MIDI engine would need to be added/changed in the FreeBSD kernel to be 
able to do that, and what the userland side of this would/should/could 
look like, I have no idea. I don't have enough knowledge about MIDI in 
this regard.

>> > 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.

I could imagine something extensible which provides base features in the 
base systems and plugins via ports. Keeping it entirely in ports with 
some kind of support from the base system userland utilities of this 
project may also be possible (maybe via some kind of plugin system for 
the base userland tools).

What I mention(ed) are simply ideas. I do not want to propose priorities 
or changes of the scope / deliverables.

Bye,
Alexander.

-- 
http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF