Hi Alan,
On 11.04.2012 19:00, Alan Horstmann wrote:
On Wednesday 11 April 2012 16:17, Daniel Mack wrote:
On 11.04.2012 12:59, Alan Horstmann wrote:
These are essentially issues in the way Portaudio interfaces; I am not suggesting driver bugs etc, but in summary:
a) The Audio 4DJ uses fixed _BE format, almost uniquely AFAICT from grepping driver source tree. Portaudio at present requests formats in the host platform endianness - so on a x86 PC an acceptable format is not available from the 'hw' device. Users seem reluctant to use 'plughw'.
Erm. Class compliant USB cards speak _LE formats only, and I'm not aware of any hardware that is able to switch endianess on a run-time configuration base.
Are you referring to USB cards? It looked to me like several PCI cards listed _BE and _LE variants of some formats in the driver?
Might be that there is hardware out there that lets the driver stack choose the audio format, but you can't rely on it. And from a hardware engineer's perspective, this is probably not easy to do in hardware, as the streaming code is likely implemented in programmable logic that is not that versatile.
From what I know, PortAudio is just a thin layer on top of ALSA and other sound APIs to ease the pain of cross-platform development of audio applications, right? What's wrong with letting ALSA convert the samples for you then?
That has been my perspective too, to use 'plughw' but some audio users believe the plug layer will necessarily give worse latency etc, and always want to get "as close as possible to the hardware".
Understood. But then you would at least need to take care for endianess format conversions and maybe even zero-padding in PortAudio.
Ok, I see your problem, but certainly, PortAudio is the place to get this fixed, not the driver.
Yes, but listing all subdevices does have it's own problems, as some cards have large numbers of them, for some reason.
The problem is probably which substreams to export to the user-API. But the PortAudio core should certainly be capable of handling subdevices.
So clearly, the issues you're seeing are due to missing features in PortAudio, and it should be fairly easy to add them there.
Well, I don't think it will be easy in fact, due to the constraints of a multi-platform API that is largely shaped by platforms other than Alsa, but it should be resolved in Portaudio, one way or another.
Thanks for your assistance,
No problem :) Let me know if I can help any further.
Daniel