[LAD] linux audio standards base?

Patrick Shirkey pshirkey at boosthardware.com
Sun Aug 9 15:22:51 UTC 2009


On 08/10/2009 12:56 AM, Robin Gareus wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Patrick Shirkey wrote:
>    
>> On 08/09/2009 10:35 PM, Kjetil S. Matheussen wrote:
>>      
>>> On Sun, 9 Aug 2009, Patrick Shirkey wrote:
>>>
>>>        
>>>> On 08/09/2009 10:12 PM, Kjetil S. Matheussen wrote:
>>>>          
>>>>> On Sun, 9 Aug 2009, Patrick Shirkey wrote:
>>>>>
>>>>>            
>>>>>> On 08/09/2009 08:12 PM, Kjetil S. Matheussen wrote:
>>>>>>              
>>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>>                  
>>>>>>> Well, there's your problem. It's great that you try out new
>>>>>>> software though, but of course then you'll get more stability
>>>>>>> issues as well.
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>>> To clarify, I have found that is difficult to get 32 bit apps to
>>>>>> connect to a 64 bit build of pulseaudio but these apps don't cause
>>>>>> stability issues with pulse. The problem is they just don't
>>>>>> connect. I can still run them directly over the alsa layer but that
>>>>>> locks the device in a standard Fedora 11 setup. I believe this
>>>>>> would affect alot of "normal" users so I would like to find a
>>>>>> workable solution that can be recommended to all packagers as a LAD
>>>>>> standard.
>>>>>>              
>>>>> No, as I said, the solution is very simple: Don't install a 64 bit
>>>>> OS. That's what's causing your problems, apparently.
>>>>>
>>>>>            
>>>> Oh, I get you now.
>>>>
>>>> So are you advocating that the official recommendation of LAD is not
>>>> to use a 64 bit system?
>>>>
>>>>          
>>> I'm not sure what you mean by official recommendation, but from what
>>> you describe, 64 bit systems can cause problems when using flash and
>>> pulseaudio.
>>>
>>>        
>> 64 bit libflashplayer is hard coded to use /usr/lib/ and on Fedora 11
>> the 64 bit alsa-libs live in /usr/lib64/. I'm not sure that is a problem
>> with a 64 bit system, libflashplayer or just Fedora's packaging policy.
>>
>> I am guessing that it affects a lot of people.
>>
>> The stability issues I have seen are not related to libflashplayer. That
>> issue is more of a usability issue in that firefox/libflashplayer
>> doesn't release the alsa device which makes it hard to use jack or other
>> apps that require access to the alsa device.
>>
>>      
> I used to be annoyed of this very much and learned to love firefox'
> flashblock plugin for that matter. However using jackplug in .asoundrc
> resolved this issue quite nicely for me and I don't use pulesaudio on
> any system here.
>
> Anyways, we're getting way off-topic from discussing a
> linux-audio-standards-base; although discussion and diversity here shows
> that it may be impossible to do so.


I think it is a part of a wider issue that a standard could be used to 
correct. I have a feeling that if we approached Adobe with an open 
letter saying that we as the flag bearers for Linux Audio highly 
recommend they provide a flexible path for the 64 bit lib then it would 
probably get to the right people.

A secondary issue that you have brought up here is that jack is very 
capable of handling many things for the desktop that pulseaudio is 
currently failing at on a 64 bit system and many people prefer to use 
jack instead of pulseaudio for that reason.

However pulse is being shipped as the default sound server for all major 
distros.  There is a major disconnect here in that jack is not designed 
to be the default server for a desktop audio system but it does fufil 
the purpose quite well in many ways whereas pulse is designed to be a 
desktop audio server but it doesn't allow for professional apps to 
connect to jack easily at the moment.

Should we not be recommending a set of guidelines for the distro 
packagers to attempt to follow and not let them dictate to us how the 
sound system should be organised?

After all we (LAD) are the ones who designed it so we are best placed to 
recommend how it should be best configured.


For example:

- A distribution should attempt to run jack as the default audio server.
- Pulseaudio should connect to jack by default and fall back to the alsa 
layer if jack is not running.
- Closed source binaries should provide flexibility for changing the 
audio library path and not be hardcoded to /usr/lib/





Patrick Shirkey
Boost Hardware Ltd


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


More information about the Linux-audio-dev mailing list