Date: Fri, 15 Dec 2023 01:34:39 +0200 From: Christos Margiolis <christos@freebsd.org> To: Alexander Leidinger <Alexander@leidinger.net> Cc: freebsd-multimedia@freebsd.org Subject: Re: RFC - Work on FreeBSD's Audio Stack Message-ID: <zplobfdklidj7iwmwzfyglkpc2qklhkxkuf3albz4iprndewcg@jdp4picbfzt4> In-Reply-To: <5240adad4ff5b341756809fe12d362c9@Leidinger.net> References: <86ttomxg11.fsf@phe.ftfl.ca> <86y1dxpjzy.fsf@phe.ftfl.ca> <5240adad4ff5b341756809fe12d362c9@Leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?zplobfdklidj7iwmwzfyglkpc2qklhkxkuf3albz4iprndewcg>