On 08/11/2009 08:59 AM, Nick Copeland wrote:
The following is all opinion which I think is what was requested:
> Here's an updated list of the possible official recommendations for
discussion:
We should not really be recommending anything and 'official' makes it
sound rather orchestrated. We should be selling the benefits of the
solution. If any attempt is made to mandate then we are going to run
into reasonable resistance from both the apps and platform to any
change as what is being proposed here increases compexity and
abstraction of the audio interface which in anybodies book is a bad thing.
Ok, so from what you are saying there is nothing particularly wrong that
the recommendations below would solve for a large enough number of
people as to make it worth suggesting any of them at all? I don't think
that I need to justify why the recommendations are offered but if they
are really not to be considered necessary then that is a different story.
The list below is simply attempting to solve as elegantly as possible
the real usability issues that currently crop up for a "normal" user
experience on 64 bit with the additional suggestion for the kernel
config as people were wondering how to get extended memory on a 32 bit
platform. I'm not sure if that last one is relevant myself but it was
suggested so it's on the list of suggestions to be considered.
Here's an additional possible recommendation that occurred to me last night.
- If using skype consider purchasing a usb phone and using that as the
audio interface instead of relying on the onboard sound device as it
will probably make your life easier.
Patrick Shirkey
Boost Hardware Ltd
- A distribution should attempt to run jack as the default audio
server and should attempt to make the process pf starting jack easy
for a non technical user.
Why should a distribution do this? There are lots of reasons why they
shouldn't.
- Pulseaudio should attempt to connect to jack by default and fall
back to the alsa layer if jack is not running.
Why should pulse audio do this? There are lots of reasons why it
shouldn't.
- Closed source binaries such as those provided by companies like
Adobe, Skype and Real Networks should provide flexibility for changing
the audio library path and not be hardcoded to /usr/lib/
Why should they do this? Skype has 400M users, Adobe at least double
that. Why should they make consideration for perhaps a small number of
hundreds of users: those that want Linux, and Audio, and 64bit? You
are welcome to change the figure of 'hundreds' into 'thousands' but
nowhere on earth does it reach anything like the number of Skype users
on 'another' platform. What are we offering Skype by way of a carrot
to make them even consider this? You have to put the request into the
perspective of it just being yet another request made of them and all
of the other requests leading to potential financial benefits to their
organisation. All Linux can offer Skype is a number of paying
subscribers, and those that fit this specific demand are very small.
- For 32 Bit systems with memory of more than 8GB we recommend
enabling CONFIG_X86_PAE in the kerneld
The limit is theoretically 4G. Its a lot lower on pretty much all
motherboards. If we put in any demands like this one it will sound
like we have no idea about what we are talking about.
- For a 64 bit desktop system please ensure the 32 bit libraries for
alsa, jack and pulseaudio are installed by default.
Is this relevant? Are you asking for just the 32 bit libraries? Both
of them?
If somebody put this proposal in front of me, personally, I would not
give it the time of day. There is no justification, no benefit being
offered, and no real necessity to do it. There is nothing compelling.
Nick.
Again, this was all opinion. The goal is a good one, the means don't
quite seem to rise up to it.
------------------------------------------------------------------------
Share your memories online with anyone you want anyone you want.
<http://www.microsoft.com/middleeast/windows/windowslive/products/photos-share.aspx?tab=1>
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
