Besides not using available hardware power (for mixing), the only problem with pulse right now is the magic buffer™, that's not going away. Streaming a pulse stream over network or from one device to another (e.g. capture card in -> onboard out) will/may induce an increasing delay, I guess because of sample rate mismatch. At least with ALSA, the supported features did work as expected; nowhere near the "official drivers" (e.g. windows) though.I honestly haven't had an issue with Pulse Audio for years
Try using it with audio hardware that does not follow the traditional desktop 2.0/4.0/5.1/7.1 output layout, for example - you'll have lots of fun. PulseAudio can be a real configuration nightmare if you're leaving the holy path of the desktop defaults - and I don't want to know what kinds of "litte or unused driver features" Poettering would argue with when confronted with the issues that follow.I honestly haven't had an issue with Pulse Audio for years, and I regularly take advantage of its ability to allow me to adjust sound output by application, and switch input and output devices on the fly.
If you want to turn your pandora as hand warmer, try this : https://pyra-handheld.com/boards/threads/cpu-stress-test.68361/But I have the opposite problem -- I live where it is often extremely cold. Unfortunately, I don't seem to stress my Pandora enough to use it as a portable hand warmer.
Afaik that's the goal on "HW-level" (channel mapping + resampling) but has still driver issues. On the other hand, leaving channels as they are up to userspace would have the benefit of being less confusing... not sure what the exact plans are.That gives me an idea, though... can't we use the DSP as a hardware mixer for the audio controller?
I do mean mixing as in mixing multiple audio streams together, that's ALSA's understanding of a hardware mixer ([HWMIX] hardware tag in their wiki).(channel mapping + resampling)
I'm thinking about plain hardware mixing for the internal DAC, I personally don't care about Bluetooth (or any external audio hardware in general) at all.If you think about per-application transitions from handset to handset and maybe to blue tooth.
ALSA natively supports hardware that accepts more than one stream per device, it just needs to be hooked up into the audio driver. The access on ALSA's HW interface will simply be non-exclusive until the driver runs out of available mixing channels.I believe having two "OSS" sinks that get mixed in-hardware would be possible on most SoCs, but someone would to configure or write the firmware for that...
I know. That's what we used to do before PA. But you'd need an ALSA driver for that -- two OSS devices are easier to explain.ALSA natively supports hardware that accepts more than one stream per device, it just needs to be hooked up into the audio driver. The access on ALSA's HW interface will simply be non-exclusive until the driver runs out of available mixing channels.