wsc1
commented
5 years ago Here's one proposed solution to the structuring with respect to the host.
The main issue is that many hosts have many entry points to their sound stack. For example, pulseaudio usually uses ALSA as a backend, AudioFlinger in Android uses the android HAL backend (which can also use ALSA). The higher level entry points are intended for sharing of audio across applications. The lower level entries are hardware abstraction layers. AudioUnits has the nice property that it unifies the HAL and higher order processing.
To address this problem, we could create a supported list of OS, ARCH, entry point triples and place them in sio in a structured fashion. Build tags could potentially be used for the entry points as well.
Each of these triples, as determined by build tags, would then be registered in package initialisation, fulfilling an interface which would allow access to the Dev structure and scanning/device change notifications.
3rd party package could also register such device access, and as in http://godoc.org/zikichombo.org/codec/#CodecFor we could add a package selection mechanism for consumers to ultimately decide the implementation.
Thoughts?
mewmew
The sio module is organised in terms of data types into devices, inputs, outputs, duplex, and packets.
The Device struct contains fields related to common functionality in OS audio device's: a way of defining (probably) supported sample rates, PCM data types, buffer sizes.
Devices can create inputs, duplex, and outputs.
Inputs manage a simplified interface to a ringbuffer, providing the consumer with access to the part of the ring buffer that is available for consumption, synchronised by channels.
Similarly, Outputs manage a simplified interface to a ringbuffer, providing the consumer with access to that part of the ring buffer which is available for writing and a way to send it back once written.
Similarly, Duplex acts just like output but assumes 2 synchronised ring buffers behind it, one for capture and one for play, or one ring buffer with space for both in and out data. These objects all have adaptors to sound.{Source,Sink,Duplex}.
A Packet allows access to the ring buffer exported as a []float64, and implementations do whatever translation might be necessary to handle this format.
This design lacks a structured way of interacting with the host, such as periph.io or even the calling context, such as generic codec interface at zikichombo.org/codec. It also lacks a mechanism to enforce or directly support the scheduling relationship between the presumably real-time device and goroutines.
I wanted to invite other criticisms and concerns.
I also wanted to state that I think, at least at this time, the lack of mechanism to enforce or directly support the scheduling relationship between the (presumably) real-time implementation and goroutines may be good, as it would open up and facilitate the possibility of assessing this for a given application or application context, which in turn is outside of the scope of a support library. I would guesstimate that in many contexts this design could achieve latency corresponding to buffer sizes of 128 frames or less at 44.1KHz, which is considered low in many contexts.
Of course, not having support for direct enforcement of latency also presents risks in terms of reliability.
After examining the work in oto and elsewhere, and the corresponding reports of successes, I do not see any design-level reasons why this should not work at least as reliably as they work. I would like to invite debate or assertions to the contrary.
Thoughts?