[LAD] linux audio standards base?

[Patrick Shirkey]

On 08/08/2009 09:57 PM, Jens M Andreasen wrote:
> On Sat, 2009-08-08 at 16:44 +1000, Patrick Shirkey wrote:
>
>    
>> Here's what I have found after extensive testing with the latest dev
>> version of pulseaudio-v0.9.16-4 and jack-0.116.1 on a 2 core amd, 4GB
>> notebook running Fedora 11.
>>
>> 1. 32 bit apps will not play on a 64 bit pulseaudio easily or at all.
>> 2. Skype, Realplayer/Helix and Flash are a pain to get working with
>> pulseaudio if they work at all.
>>      
>
> These two items are related, right? Does it go away with a
> 32bit/extended kernel?
>
>    


I haven't tested with a 32 bit system. I'm not sure if I will get the 
time for that. I don't think in this case it has much to do with the 
kernel. I think it is because pulse is compiled for 64 bit and the apps 
are looking for 32 bit libs.

It would be fairly simple if there was a pulseaudio solution similar to 
nsplugin wrapper for all 32 bit binary apps to be plugged into. The 
other option I have is to build a 32 bit version of the pulse libs for 
my machine. I haven't had time to work out exactly how to do this yet. 
Colin Guthrie has provided some tips on the pulse list which I may get 
time to look into further in the next few weeks. Technically this is 
already handled by the Fedora packaging team but the versions of pulse 
in the Fedora packages is 0.9.15 and the dev version is 0.9.16 and there 
is a known incompatibility to be worked around as well as unknown bugs 
which mean I need to build the 32 bit libs myself.


>> 3. Pulse is unstable when connected to jack.
>> 4. If Firefox (3.5.2) is used to play an audio stream over alsa with
>> flash or realplayer (because they cannot get access to PA 32 bit libs)
>> it doesn't release the device when the stream is finished making it
>> very confusing/frustrating when other apps don't work even though no
>> sound is running on the system and forcing the user to close.kill
>> firefox in order to get access to the device.
>> 5. Gnome-volume-control is unstable, buggy and misleading at times
>> although it mostly works well.
>>      
>
> Here is one thing I don't like either. The layout and ordering  of the
> volume controls are unrelated to the routing and how the controls are to
> be used.
>
> Like this would make some sense:
>
> [Front][Center][LFE][Side][Surround] [Master] ¦ [Mic 1][Mic 2][Line] ...
>
> But like this isn't really helpful:
>
> [Front][Front Mic][Front Mic Boost] ... ... ... [Microphone] ...
>
>
> Where one 'Front' is the placement of the input jack (on the box) and
> the other 'Front' is where you would place your speakers (if that is
> what the port is used for.)
>
> The layout and order is inherited from the ALSA driver who does not know
> shit about the meaning of the labels, at least not much :)
>
>    
>> 6. Disconnecting jack apps and playing audio through PA while
>> connected to jack can bring down the whole system including the jack
>> and the alsa drivers but usually just PA gets fried which is mostly
>> acceptable while testing but useless for real world cases.
>>      
>
> That sounds really serious. You mean like a frozen machine or just
> inexplicable silence?
>
>    


This machine stays up but the audio drivers did fall over a couple of 
times. In this case the silence wasn't inexplicable as I was carefully 
monitoring the whole system but I imagine it would be very frustrating 
for a non technical user if they were using pulse->jack in it's current 
state.



Cheers.


Patrick Shirkey
Boost Hardware Ltd




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20090808/9b3d6cd1/attachment.html>