[Portaudio] Alsa: support for sub-device & 24-bit BE format only
gineera at aspect135.co.uk
Wed Apr 4 18:23:46 EDT 2012
I was hoping we could move to a situation where the discussion would not be
spread out as replies to various chunks of various emails, but it seems we
are stuck with it ;)
On Wednesday 04 April 2012 02:19, you wrote:
> There seem to me to be only two issues:
> 1) Without Dmitry's patch (or equivalent) there is no way to access some
> hw devices from PA. Given that PA currently favours hw over plughw this
> is a bug imho, and some version of Dmitry's fix is a valid change.
Well, I am unaware of the actual exact problem that lead to these changes, but
surely the devices are accessed OK, just endian swapped, or in fact not
swapped. My rough impression is that having a _BE soundcard on a _LE
platform results in data being sent _BE if you select a low-level device,
which in effect is the user saying 'don't alter the data you send me'. Alsa
is fully capable of sorting out all these issues providing the correct
interface is used.
> 2) There is a need to clarify which ALSA device access methods PA
> supports, from hw on up the abstraction chain.
Richard's discussion was very helpful.
But, I am now thinking that there is actually an even wider 3rd issue. I
think there is a fundamental mistake in the way Portaudio handles/enumerates
the devices. This endian problem has simply helped to expose it.
At present the devices are first a list of each soundcard on the system, then
a list of the Alsa virtual pcm devices (I will refer to them as 'Vpcm's) in
the configuration, ignoring several. But this is wrong, since each Vpcm can
apply to each soundcard!!! When a Vpcm is used without a number following,
it defaults to the first card (but this can be changed in the config). So
'front:2' is a valid way to apply the 'front' virtual to the third card
(since they are zero-indexed). Some of the Vpcms can have device and
sub-device values as well, eg plughw:1,2,0. Each Vpcm definition can be
card-type specific, so something like 'surround51' ensures the correct data
goes to each jack socket. 'hw:0,0' is a Vpcm that accesses the hardware
without performing any conversions and therefore it is no surprise that it
does not support non-card-native endianess. But 'plughw:0,0' will allow
non-card-native formats to be requested from Alsa.
> Having read the various comments, I think that it will be necessary to
> continue to support either direct access of the hw device, or some
> equivalent via plughw that accomodates everyone's requirements.
> If you feel that dealing with Dmitry's changes is getting in the way of
> addressing other issues, or is an ongoing stability risk, then I think
> we should roll it back and develop a cleaner fix on a branch.
Really, I do - having spent hours trying to crystalize thinking, and crafting
emails to express that, on this one issue. Am I being hard??? There is a
couple of one-line fixes and latency test results I was trying to finalise,
plus raising several new tickets. Cleaning up on a branch would be
> My concerns about Dmitry's patch are mainly around stability,
> correctness and clenliness -- the patch has obviously caused disruptions
> that could have been avoided if there had been more attention to this --
> ending the disruption should be given priority.
> In short: I agree that we don't want trunk broken. Due care needs to be
> taken when working on shared code.
> On the other hand, given that the patch is a fix for a genuine
> shortcoming in PA, I don't think we need to resolve (2) before resolving
> A first step would be to create two tickets for (1) and (2) with links
> to this thread in the mailing list archive.
So is (1) the endian issue as manifested by the 'Audio4DJ' soundcard, and (2)
is the choice of Alsa virtual devices? Might there then be (3), incorrect
Alsa enumeration of soundcards and virtual devices?
Anyway, I am going to leave it to your judgement now,
More information about the Portaudio