Re: [LAD] linux audio standards base?

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

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Sun Aug 9 20:15:02 2009