[Portaudio] Alsa: support for sub-device & 24-bit BE format only

[Alan Horstmann]

Hi Ross,

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 
preferable, IMHO.

> 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
> (1).
>
> 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,

Regards

Alan