[LAD] linux audio standards base?

[Sean Corbett]

I'm not a developer, just interested in Linux audio development
because I use Linux audio software almost daily, and as such I've been
lurking on this list for awhile.  So this is just a practical
suggestion / brainstorming idea, not meant to incur flames (I wish I
could heat my studio by the flames this list generates).  One
complaint I've seen raised a number of times is that in the world of
Linux, especially the audio realm, there are too many choices and not
enough decisions made.  In the wider scope, The Linux Foundation is
trying to address this by maintaining a standards base to help promote
open standards across mainstream distros... So here's the idea:  why
not make one of the responsibilities of the Linux Audio Consortium be
establishing and maintaining a standards base?  As far as I can tell
from http://linuxaudio.org/about , it's not currently one of the
Consortium's roles.  I.e., there could be a formal document that says
in a nutshell, "If you want your Linux audio application to integrate
seamlessly on most audio-centric distros, here's what it should
support.  And, if you want your pro-audio-centric distro to be
seamlessly compatible with all these great apps, here's what it should
include and how it should work."  Of course it would be a voluntary
standards base, and every developer / distro team can still do
whatever they like, so that innovation can continue... but as
protocols/interfaces/frameworks/whatever are developed and show their
merit, they can be included in the standards base, and
old/deprecated/redundant things removed, so that people aren't wasting
their time supporting old code.  So to sum it up, *someone* needs to
make some tough decisions, or Linux audio will continue to stagnate...
why not the Consortium?  It's the only real Linux audio "authority" or
central point of contact that I know of.

I'm sure there are many reasons this is a silly idea -- lack of time,
disagreements on what should be standardized, etc. -- but as I said
it's just an idea.  I'd love some constructive criticism, even if it
just leads to a completely different idea getting implemented.  By the
way, I apologize that this is basically just another "here's my idea
about what everyone else should do" kind of e-mails.  I could maintain
a website and/or provide free hosting for the standards document(s),
if need be.

-Sean Corbett
blacktownsound.com (<- pardon the shameless spam)
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Jens M Andreasen]

On Fri, 2009-08-07 at 10:50 -0400, Sean Corbett wrote:
>  Of course it would be a voluntary
> standards base, and every developer / distro team can still do
> whatever they like, so that innovation can continue... but as
> protocols/interfaces/frameworks/whatever are developed and show their
> merit, they can be included in the standards base, and
> old/deprecated/redundant things removed, ...

You are on your way to define a moving target rather than a standard
here. A standard is more like the "qwerty" layout which you can love or
hate, the point being that the keys ain't moving around from one season
to another. 

[Mmm ... TCP/IP networking might have been a better example.]

That being said, what are the points that a distro must consider to be
truely catering for sound. What are the targets for starters?

* Entertainment: Everybody will vote for this, piratebayed or not. This
is what Pulse is doing well if I have understood previous discussions. 

* Entertainment production: Perhaps only 10% of the population will find
this important, though 10% is still a million Linux users or so. This is
what Jack is aimed at and works as advocated IFF you have an RT-kernel,
else you are pretty much fried ... 
--> Should an RT-kernel be marked as a dependency for Jack? I would say
so. 

* Serious Gaming: I have no idea what the status of this point might be
these days. 

* Other?

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Patrick Shirkey]

On 08/08/2009 10:32 AM, Jens M Andreasen wrote:

On Fri, 2009-08-07 at 10:50 -0400, Sean Corbett wrote:
   

  Of course it would be a voluntary
standards base, and every developer / distro team can still do
whatever they like, so that innovation can continue... but as
protocols/interfaces/frameworks/whatever are developed and show their
merit, they can be included in the standards base, and
old/deprecated/redundant things removed, ...
 


You are on your way to define a moving target rather than a standard
here. A standard is more like the "qwerty" layout which you can love or
hate, the point being that the keys ain't moving around from one season
to another.

[Mmm ... TCP/IP networking might have been a better example.]

That being said, what are the points that a distro must consider to be
truely catering for sound. What are the targets for starters?

* Entertainment: Everybody will vote for this, piratebayed or not. This
is what Pulse is doing well if I have understood previous discussions.
   



Not as well as you might expect.

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.

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.
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.
7. If alsa goes down or is restarted audio settings on my hda-intel 
onboard device are often either not saved correctly or not reinstated 
correctly.
8. SELinux can get in the way and users may need to be manually assigned 
to PA groups.


Kjetil has reported better performance with a more powerful machine but 
my machine is certainly not a pig so things are pretty bad for most 
"normal" users.




* Entertainment production: Perhaps only 10% of the population will find
this important, though 10% is still a million Linux users or so. This is
what Jack is aimed at and works as advocated IFF you have an RT-kernel,
else you are pretty much fried ...
-->  Should an RT-kernel be marked as a dependency for Jack? I would say
so.
   



Basically in this case we have jack and it works very well for audio but 
if combined with video there are several usability issues that crop up 
as many of the video apps want to use jack but if PA is running that is 
not possible on all current distros except maybe 64Studio which ships 
with jack2.





* Serious Gaming: I have no idea what the status of this point might be
these days.

   


I  guess a lot of games currently fall under the wine banner in which 
case they will may have the same problems as skype, etc... I'm not sure 
how well integrated the wine pulse plugin is as I have never used it.


However we also have jackbridge and that works very well for 
transmission with energyXT and VSTHost.



Patrick Shirkey
Boost Hardware Ltd

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Jens M Andreasen]

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?

> 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?

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [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




___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Gabriel M. Beddingfield]

On Sat, 8 Aug 2009, Jens M Andreasen wrote:
>
> That being said, what are the points that a distro must consider to be
> truely catering for sound. What are the targets for starters?
>
> * Entertainment: Everybody will vote for this, piratebayed or not. This
> is what Pulse is doing well if I have understood previous discussions.
>
> * Entertainment production: Perhaps only 10% of the population will find
> this important, though 10% is still a million Linux users or so. This is
> what Jack is aimed at and works as advocated IFF you have an RT-kernel,
> else you are pretty much fried ...
> --> Should an RT-kernel be marked as a dependency for Jack? I would say
> so.
>
> * Serious Gaming: I have no idea what the status of this point might be
> these days.
>
> * Other?

* Profit!!!

:-P

-Gabriel

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Kjetil S. Matheussen]

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.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Patrick Shirkey]

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.


I am finding stability issues with 64 bit apps connecting to a 64 bit 
build of pulseaudio when it is connected to a 64 bit build of jack which 
uses 64 bit alsa libs on a standard 64 bit kernel. I don;t have 
stability issues with jack when pulse is not being used. I have run jack 
for days on this machine.


In my testing I have found that pulseaudio is unstable when using 64 bit 
apps. I have found that it is very difficult to get apps built for 32 
bit environments to play nicely with pulse audio on a standard Fedora 11 
setup even when I have the 32 bit pulse libs installed.


One annoying issue is libflashplayer that seems to be hard coded to 
search in /usr/lib instead of /usr/lib64. This causes conflicts with 
apps like realplayer and skype which are looking for the 32 bit libs in 
/usr/lib/alsa-lib. In order to get libflashplayer to run through pulse I 
had to link the 64 bit pulse-alsa libs from /usr/lib64/alsa-lib to 
/usr/lib/alsa-lib.


The instability could also be related to running a standard kernel not 
rt kernel. Although this machine is powerful enough to run hundreds of 
audio streams asynchronously so I don't think it is a hardware issue.








Patrick Shirkey
Boost Hardware Ltd





___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
   
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Kjetil S. Matheussen]

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.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Patrick Shirkey]

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?



Cheers.



Patrick Shirkey
Boost Hardware Ltd



___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Kjetil S. Matheussen]

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.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Patrick Shirkey]

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.









Patrick Shirkey
Boost Hardware Ltd



___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Arnold Krille]

On Sunday 09 August 2009 14:12:56 Kjetil S. Matheussen wrote:
> No, as I said, the solution is very simple: Don't install a 64 bit OS.
> That's what's causing your problems, apparently.

Helloo! Please leave the 20th century where it belongs. Nowadays 64bit are 
normal with new computers and its a terrible waste not to use them (reminds me 
of "640kB should be enough for everybody").

If the combination of 64bit and 32bit-binary-only apps is broken, its the 
developers or the distributions task to fix it. And the users task to point out 
the problems and demand the fix.

Looking away by only using 32bits is _not_ the solution. And please stop 
telling that "solution" to other people. We are in the 21th century after 
all...

Arnold


signature.asc
Description: This is a digitally signed message part.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Robin Gareus]

-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.

robin

> 
> 
> 
> 
> 
> 
> 
> Patrick Shirkey
> Boost Hardware Ltd
> 
> 
> 
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEUEARECAAYFAkp+46gACgkQeVUk8U+VK0K8vACYr2mgrWeE2ZBWcKMY5Hp5cHhv
hwCdGbocQ8D6gCOqhaKDauPARvXOqVc=
=pHKD
-END PGP SIGNATURE-
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Patrick Shirkey]

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 mail

Re: [LAD] linux audio standards base?

[Kjetil S. Matheussen]

Arnold Krille:
> On Sunday 09 August 2009 14:12:56 Kjetil S. Matheussen wrote:
>> No, as I said, the solution is very simple: Don't install a 64 bit OS.
>> That's what's causing your problems, apparently.
>
> Helloo! Please leave the 20th century where it belongs. Nowadays 64bit are
> normal with new computers and its a terrible waste not to use them (reminds me
> of "640kB should be enough for everybody").
>
> If the combination of 64bit and 32bit-binary-only apps is broken, its the
> developers or the distributions task to fix it. And the users task to point 
> out
> the problems and demand the fix.
>
> Looking away by only using 32bits is _not_ the solution. And please stop
> telling that "solution" to other people. We are in the 21th century after
> all...
>

Seems like you have some issues about something.? The case is that
a 32 bit OS works, while a 64 bit OS don't. So until the 64 bit
issues are fixed, using a 32 bit OS is a perfectly fine solution
to the problem. I installed a 32 bit OS because I didn't want
the kind of trouble Patrick has, and others who don't want
that kind trouble should do the same.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Jens M Andreasen]

On Sun, 2009-08-09 at 16:31 +0200, Arnold Krille wrote:

> Helloo! Please leave the 20th century where it belongs. Nowadays 64bit are 
> normal with new computers and its a terrible waste not to use them (reminds 
> me 
> of "640kB should be enough for everybody").

I have 2GB here which is twice as much as I really wanted, but the
smaller sticks were out of stock. The only reason I can come to think of
to use even more memory, is by replacing the applets from WindowMaker
with their Gnome counterparts, which will then run ten times slower and
have twenty times the memory footprint.

What single application - apart from Mozilla - really needs more than
4GB?

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Patrick Shirkey]

On 08/10/2009 01:42 AM, Kjetil S. Matheussen wrote:

Arnold Krille:
   

On Sunday 09 August 2009 14:12:56 Kjetil S. Matheussen wrote:
 

No, as I said, the solution is very simple: Don't install a 64 bit OS.
That's what's causing your problems, apparently.
   

Helloo! Please leave the 20th century where it belongs. Nowadays 64bit are
normal with new computers and its a terrible waste not to use them (reminds me
of "640kB should be enough for everybody").

If the combination of 64bit and 32bit-binary-only apps is broken, its the
developers or the distributions task to fix it. And the users task to point out
the problems and demand the fix.

Looking away by only using 32bits is _not_ the solution. And please stop
telling that "solution" to other people. We are in the 21th century after
all...

 


Seems like you have some issues about something.? The case is that
a 32 bit OS works, while a 64 bit OS don't. So until the 64 bit
issues are fixed, using a 32 bit OS is a perfectly fine solution
to the problem. I installed a 32 bit OS because I didn't want
the kind of trouble Patrick has, and others who don't want
that kind trouble should do the same.
   



I understand where you are coming from and I agree that it is a good 
recommendation. 3 years ago I would have been with you 100% however I 
have been running a 64 bit os for the past three years and the sound 
issue is the only thing that I keep coming up against the is so 
frustrating. It's like we are behind the curve in many ways.


I really think we can do better and making some official recommendations 
specific to audio config on 64 bit other than "don't use 64 bit" or 
specific to working with audio apps other "than disable pulseaudio" 
seems like a good idea to me.








Patrick Shirkey
Boost Hardware Ltd





___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
   
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Arnold Krille]

On Sunday 09 August 2009 19:06:15 Jens M Andreasen wrote:
> On Sun, 2009-08-09 at 16:31 +0200, Arnold Krille wrote:
> > Helloo! Please leave the 20th century where it belongs. Nowadays 64bit
> > are normal with new computers and its a terrible waste not to use them
> > (reminds me of "640kB should be enough for everybody").
>
> I have 2GB here which is twice as much as I really wanted, but the
> smaller sticks were out of stock. The only reason I can come to think of
> to use even more memory, is by replacing the applets from WindowMaker
> with their Gnome counterparts, which will then run ten times slower and
> have twenty times the memory footprint.
>
> What single application - apart from Mozilla - really needs more than
> 4GB?

Ardour (by the way of the os) for the cache of the soundfiles.
Linuxsampler (by the way of the os) to hold more of the samples data in 
memory.
Aeolus (by the way of the os) to cache the generated samples.

The only thing to make disk-access faster apart from faster disks and 
controllers is to have more memory for caching. And the more, the better.

And please don't start arguing why you should use 64bits if all is well with 
32bits. That is exactly the kind of argumentation the citation above came 
from. And here is another one: "I think 5 computers is enough for the while 
world". (Luckily the world didn't listen to neither of these two guys.)

Have fun,

Arnold


signature.asc
Description: This is a digitally signed message part.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[alex stone]

Well spoken Arnold.

The bigger picture here is the conditioning computer users have been
subjected to from the first moment Blinky Bill attached a mouse to a
box.
As one who spent most of his working life struggling with
"professional" audio and midi apps in a win and mac environment,
before i got to the present day, it was apparent ten years ago that
switching to 64bit as viable evolution from 32bit wasn't going to
happen because it would have required 1) a lot of rewritten software
for little apparent profit, and 2) windows changing their tune, which
wasn't going to happen, because of little apparent profit. So users
all over the planet got suckered into thinking 32bit
wassufficient.

It still goes on, and in our little slice of the planet, it's a
tragedy, because the majority of users are still stuck in that "32bit"
paradigm. I think we all know that if everything switched to 32 bit
all of a sudden, it would take about a week for most to get
acclimatised, and we'd be off again. For too long we were stuck with
messy workarounds to try and extract more memory use from 32bit
setups, including the infamous /3gb switch in win that either worked
or toasted your setup, often in the same week.

As a living example of the difference between 32bit and 64bit in my
particular working environment, i only have to cast my mind back to my
gigastudio time, in multiple boxes, to the present day, where more
gets done in one box. 64bit.

Again, this seems to be a discussion of serious use versus domestic
use, and our old friend PA has raised his head again.

I'll ask the obvious question here.
Jackd is often hammered as a RT only option, yet there are users who
have it in non RT environments. PA is used in a non RT environment.
The figures for performance, in this particular case seem in favour of
Jackd  for stability, ease of use, and ability to take pretty well
everything thrown at it.

Why then did the fairly rapid decision get made to adopt PA, and not
the more obvious and united potential solution to port apps to jack,
and incorporate a "safer" setting in jack for those whose appetites
are for desktop fare?

It is, as Arnold rightly said, the 21st century, and why, after the
plethora of posts over the last 12 months bemoaning the sound
challenges and lack of cohesion in the linux world, did yet another
fracture appear, as one gang sought to impose "their" particular
solution? Had all those devs jumped in and worked at a total solution,
we'd all be swimming in cream now, and the rest of the computer world
would be sick with envy, given the far greater potential for a great
time in linux.

32bit versus 64bit isn't about memory, or processor, or anything else
but continuing the urban myth that it's "better to use 32bit for
desktops." It's nonsense. It's about the stranglehold on the market by
one company who won't take the jump, because they won't make enough
cash out of it. Following this trend only further perpetuates the
myth, and breathes continuing life into a format that reeks of
rightfully aromatic extinction...

2 roubles worth, as always,

Alex.

On Sun, Aug 9, 2009 at 10:56 PM, Arnold Krille wrote:
> On Sunday 09 August 2009 19:06:15 Jens M Andreasen wrote:
>> On Sun, 2009-08-09 at 16:31 +0200, Arnold Krille wrote:
>> > Helloo! Please leave the 20th century where it belongs. Nowadays 64bit
>> > are normal with new computers and its a terrible waste not to use them
>> > (reminds me of "640kB should be enough for everybody").
>>
>> I have 2GB here which is twice as much as I really wanted, but the
>> smaller sticks were out of stock. The only reason I can come to think of
>> to use even more memory, is by replacing the applets from WindowMaker
>> with their Gnome counterparts, which will then run ten times slower and
>> have twenty times the memory footprint.
>>
>> What single application - apart from Mozilla - really needs more than
>> 4GB?
>
> Ardour (by the way of the os) for the cache of the soundfiles.
> Linuxsampler (by the way of the os) to hold more of the samples data in
> memory.
> Aeolus (by the way of the os) to cache the generated samples.
>
> The only thing to make disk-access faster apart from faster disks and
> controllers is to have more memory for caching. And the more, the better.
>
> And please don't start arguing why you should use 64bits if all is well with
> 32bits. That is exactly the kind of argumentation the citation above came
> from. And here is another one: "I think 5 computers is enough for the while
> world". (Luckily the world didn't listen to neither of these two guys.)
>
> Have fun,
>
> Arnold
>
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>
>



-- 
www.openoctave.org

midi-subscr...@openoctave.org
development-subscr...@openoctave.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxa

Re: [LAD] linux audio standards base?

[alex stone]

That should read "..if everything switched to 64bit all of a sudden"
Sorry about that.





On Sun, Aug 9, 2009 at 11:24 PM, alex stone wrote:
> Well spoken Arnold.
>
> The bigger picture here is the conditioning computer users have been
> subjected to from the first moment Blinky Bill attached a mouse to a
> box.
> As one who spent most of his working life struggling with
> "professional" audio and midi apps in a win and mac environment,
> before i got to the present day, it was apparent ten years ago that
> switching to 64bit as viable evolution from 32bit wasn't going to
> happen because it would have required 1) a lot of rewritten software
> for little apparent profit, and 2) windows changing their tune, which
> wasn't going to happen, because of little apparent profit. So users
> all over the planet got suckered into thinking 32bit
> wassufficient.
>
> It still goes on, and in our little slice of the planet, it's a
> tragedy, because the majority of users are still stuck in that "32bit"
> paradigm. I think we all know that if everything switched to 32 bit
> all of a sudden, it would take about a week for most to get
> acclimatised, and we'd be off again. For too long we were stuck with
> messy workarounds to try and extract more memory use from 32bit
> setups, including the infamous /3gb switch in win that either worked
> or toasted your setup, often in the same week.
>
> As a living example of the difference between 32bit and 64bit in my
> particular working environment, i only have to cast my mind back to my
> gigastudio time, in multiple boxes, to the present day, where more
> gets done in one box. 64bit.
>
> Again, this seems to be a discussion of serious use versus domestic
> use, and our old friend PA has raised his head again.
>
> I'll ask the obvious question here.
> Jackd is often hammered as a RT only option, yet there are users who
> have it in non RT environments. PA is used in a non RT environment.
> The figures for performance, in this particular case seem in favour of
> Jackd  for stability, ease of use, and ability to take pretty well
> everything thrown at it.
>
> Why then did the fairly rapid decision get made to adopt PA, and not
> the more obvious and united potential solution to port apps to jack,
> and incorporate a "safer" setting in jack for those whose appetites
> are for desktop fare?
>
> It is, as Arnold rightly said, the 21st century, and why, after the
> plethora of posts over the last 12 months bemoaning the sound
> challenges and lack of cohesion in the linux world, did yet another
> fracture appear, as one gang sought to impose "their" particular
> solution? Had all those devs jumped in and worked at a total solution,
> we'd all be swimming in cream now, and the rest of the computer world
> would be sick with envy, given the far greater potential for a great
> time in linux.
>
> 32bit versus 64bit isn't about memory, or processor, or anything else
> but continuing the urban myth that it's "better to use 32bit for
> desktops." It's nonsense. It's about the stranglehold on the market by
> one company who won't take the jump, because they won't make enough
> cash out of it. Following this trend only further perpetuates the
> myth, and breathes continuing life into a format that reeks of
> rightfully aromatic extinction...
>
> 2 roubles worth, as always,
>
> Alex.
>
> On Sun, Aug 9, 2009 at 10:56 PM, Arnold Krille wrote:
>> On Sunday 09 August 2009 19:06:15 Jens M Andreasen wrote:
>>> On Sun, 2009-08-09 at 16:31 +0200, Arnold Krille wrote:
>>> > Helloo! Please leave the 20th century where it belongs. Nowadays 64bit
>>> > are normal with new computers and its a terrible waste not to use them
>>> > (reminds me of "640kB should be enough for everybody").
>>>
>>> I have 2GB here which is twice as much as I really wanted, but the
>>> smaller sticks were out of stock. The only reason I can come to think of
>>> to use even more memory, is by replacing the applets from WindowMaker
>>> with their Gnome counterparts, which will then run ten times slower and
>>> have twenty times the memory footprint.
>>>
>>> What single application - apart from Mozilla - really needs more than
>>> 4GB?
>>
>> Ardour (by the way of the os) for the cache of the soundfiles.
>> Linuxsampler (by the way of the os) to hold more of the samples data in
>> memory.
>> Aeolus (by the way of the os) to cache the generated samples.
>>
>> The only thing to make disk-access faster apart from faster disks and
>> controllers is to have more memory for caching. And the more, the better.
>>
>> And please don't start arguing why you should use 64bits if all is well with
>> 32bits. That is exactly the kind of argumentation the citation above came
>> from. And here is another one: "I think 5 computers is enough for the while
>> world". (Luckily the world didn't listen to neither of these two guys.)
>>
>> Have fun,
>>
>> Arnold
>>
>> ___
>> Linux-audio-dev mailing 

Re: [LAD] linux audio standards base?

[Fons Adriaensen]

On Sun, Aug 09, 2009 at 08:56:21PM +0200, Arnold Krille wrote:

> > What single application - apart from Mozilla - really needs more than
> > 4GB?
> 
> Ardour (by the way of the os) for the cache of the soundfiles.
> Linuxsampler (by the way of the os) to hold more of the samples data in 
> memory.
> Aeolus (by the way of the os) to cache the generated samples.

Absolutely not true.

Aeolus takes around 120 MB of which 40 MB are shared (mostly X11).

My main machine at home has just 512 MB. I've used it to mix 24-track
Ardour sessions, it also runs Aeolus and Linuxsampler (and also both
together) without any problem.

Of course if you use a bloated desktop that probably wouldn't work.

Ciao,

-- 
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Arnold Krille]

On Sunday 09 August 2009 22:20:50 Fons Adriaensen wrote:
> On Sun, Aug 09, 2009 at 08:56:21PM +0200, Arnold Krille wrote:
> > > What single application - apart from Mozilla - really needs more than
> > > 4GB?
> > Ardour (by the way of the os) for the cache of the soundfiles.
> > Linuxsampler (by the way of the os) to hold more of the samples data in
> > memory.
> > Aeolus (by the way of the os) to cache the generated samples.
> Absolutely not true.
> Aeolus takes around 120 MB of which 40 MB are shared (mostly X11).
> My main machine at home has just 512 MB. I've used it to mix 24-track
> Ardour sessions, it also runs Aeolus and Linuxsampler (and also both
> together) without any problem.

? Huh, thats why I said "by the way of the os". I mean that the more memory 
you have (and do not use for more bloated applications:), the more memory the 
system uses for caching of disk-access.
If aeolus is small that is good. Because that leaves more memory to cache the 
samples (outside of aeolus itself).

Arnold


signature.asc
Description: This is a digitally signed message part.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Fons Adriaensen]

On Sun, Aug 09, 2009 at 10:59:29PM +0200, Arnold Krille wrote:

> If aeolus is small that is good. Because that leaves more memory to cache the 
> samples (outside of aeolus itself).

The 120 MB includes all precomputed wavetables, and they
are loaded permanently in memory. There is nothing else to
be cached.

Ciao,

-- 
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[David Robillard]

On Sun, 2009-08-09 at 23:24 +0400, alex stone wrote:
> It still goes on, and in our little slice of the planet, it's a
> tragedy, because the majority of users are still stuck in that "32bit"
> paradigm.

Even on Linux?  Really?

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Jens M Andreasen]

On Sun, 2009-08-09 at 16:31 +0200, Arnold Krille wrote:

> Looking away by only using 32bits is _not_ the solution.

How about CONFIG_X86_PAE?

Wouldn't this allow for a balance between "domestic use" as well as a
handful of memory hungry audio/video applications (or up to 64GB of
buffered data)

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Loki Davison]

On Mon, Aug 10, 2009 at 3:06 AM, Jens M
Andreasen wrote:
> On Sun, 2009-08-09 at 16:31 +0200, Arnold Krille wrote:
>
>> Helloo! Please leave the 20th century where it belongs. Nowadays 64bit are
>> normal with new computers and its a terrible waste not to use them (reminds 
>> me
>> of "640kB should be enough for everybody").
>
> I have 2GB here which is twice as much as I really wanted, but the
> smaller sticks were out of stock. The only reason I can come to think of
> to use even more memory, is by replacing the applets from WindowMaker
> with their Gnome counterparts, which will then run ten times slower and
> have twenty times the memory footprint.
>
> What single application - apart from Mozilla - really needs more than
> 4GB?
>
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>

Given that 8gb of ram costs less here than an an sm57 mic, why bother
with little sticks?

Loki
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Patrick Shirkey]

On 08/10/2009 12:21 PM, Jens M Andreasen wrote:

On Sun, 2009-08-09 at 16:31 +0200, Arnold Krille wrote:

   

Looking away by only using 32bits is _not_ the solution.
 


How about CONFIG_X86_PAE?

Wouldn't this allow for a balance between "domestic use" as well as a
handful of memory hungry audio/video applications (or up to 64GB of
buffered data)
   


Looks very useful for many "desktop" use cases. However I note from this 
page: (first hit on google)


http://cateee.net/lkddb/web-lkddb/X86_PAE.html

"PAE is required for NX support, and furthermore enables larger 
swapspace support for non-overcommit purposes. It has the cost of more 
pagetable lookup overhead, and also consumes more pagetable space per 
process."


That suggests to me a similar situation to a win modem or auto resampling.

- Should this be a recommended method coming from LAD?


BTW, it would be interesting to get some real world feedback from anyone 
who has this enabled already on a 32 bit platform.








Patrick Shirkey
Boost Hardware Ltd



___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
   
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Jens M Andreasen]

On Mon, 2009-08-10 at 15:22 +1000, Patrick Shirkey wrote:

> "PAE is required for NX support, and furthermore enables larger
> swapspace support for non-overcommit purposes. It has the cost of more
> pagetable lookup overhead, and also consumes more pagetable space per
> process."
> 
> That suggests to me a similar situation to a win modem or auto
> resampling. 
> 

Why? The sentences above do not specify what is compared and only
handwavingly suggests a cost of "more"  ... Mind you, 64bit pointers
crawling all over the place ain't free either.

> - Should this be a recommended method coming from LAD?
> 

Rather than suggesting something that is defunkt by default, yes.

> 
> BTW, it would be interesting to get some real world feedback from
> anyone who has this enabled already on a 32 bit platform.
> 

This would most likely be enabled by default for anybody who has
installed a 32bit distro on a machine with 8GB memory.


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Patrick Shirkey]

On 08/10/2009 05:14 PM, Jens M Andreasen wrote:

On Mon, 2009-08-10 at 15:22 +1000, Patrick Shirkey wrote:

   

"PAE is required for NX support, and furthermore enables larger
swapspace support for non-overcommit purposes. It has the cost of more
pagetable lookup overhead, and also consumes more pagetable space per
process."

That suggests to me a similar situation to a win modem or auto
resampling.

 


Why? The sentences above do not specify what is compared and only
handwavingly suggests a cost of "more"  ... Mind you, 64bit pointers
crawling all over the place ain't free either.

   


Simply because they don't specify the real world cost of using the method.



- Should this be a recommended method coming from LAD?

 


Rather than suggesting something that is defunkt by default, yes.

   


I Absolutely agree. I will add that as it's coming from LAD it should 
ideally be the most efficient and future proof option with fallback for 
situations where it is not possible to implement the complete 
recommendation.


I consider this approach part of the fallback.



BTW, it would be interesting to get some real world feedback from
anyone who has this enabled already on a 32 bit platform.

 


This would most likely be enabled by default for anybody who has
installed a 32bit distro on a machine with 8GB memory.


   


Hmmm, I wonder how many people are in that situation?

IIUC the only way to get 8GB or RAM onto a normal mobo is with a quad 
core 64 bit system. Are you suggesting that there are a lot of people 
who have one of these beasts who are running 32 bit OS on it?


I know I'm not.

Just out of interest I wonder if Fons would be willing to run 32 bit on 
the new system  he is looking at purchasing?


Can we get a show of hands? Is anyone running 32 bit with 8Gb of memory? 
How about 64 bit with the same specs?




Cheers.



Patrick Shirkey
Boost Hardware Ltd




___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Arnold Krille]

On Sunday 09 August 2009 23:47:17 Fons Adriaensen wrote:
> On Sun, Aug 09, 2009 at 10:59:29PM +0200, Arnold Krille wrote:
> > If aeolus is small that is good. Because that leaves more memory to cache
> > the samples (outside of aeolus itself).
> The 120 MB includes all precomputed wavetables, and they
> are loaded permanently in memory. There is nothing else to
> be cached.

Ah, okay. So aeolus was a bad example...

Arnold


signature.asc
Description: This is a digitally signed message part.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Patrick Shirkey]

On 08/10/2009 05:44 PM, Arnold Krille wrote:

On Sunday 09 August 2009 23:47:17 Fons Adriaensen wrote:
   

On Sun, Aug 09, 2009 at 10:59:29PM +0200, Arnold Krille wrote:
 

If aeolus is small that is good. Because that leaves more memory to cache
the samples (outside of aeolus itself).
   

The 120 MB includes all precomputed wavetables, and they
are loaded permanently in memory. There is nothing else to
be cached.
 


Ah, okay. So aeolus was a bad example...

   


Oooh snap!



Here's an updated list of the possible official recommendations for 
discussion:



- 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.
- Pulseaudio should attempt to connect to jack by default and fall back 
to the alsa layer if jack is not running.
- 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/
- For 32 Bit systems with memory of more than 8GB we recommend enabling 
CONFIG_X86_PAE in the kernel
- For a 64 bit desktop system please ensure the 32 bit libraries for 
alsa, jack and pulseaudio are installed by default.




cheers.


Patrick Shirkey
Boost Hardware Ltd


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Jens M Andreasen]

On Mon, 2009-08-10 at 18:01 +1000, Patrick Shirkey wrote:

> Oooh snap!

:-D

> - 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/
> - For 32 Bit systems with memory of more than 8GB we recommend
> enabling CONFIG_X86_PAE in the kernel

Hey wait a millisec, is the problem really with Mozilla/Firefox being
compiled for 64bit and it will go away if it is compiled for 32bit
instead so it can use the Adobe, Real etc plugins as supplied by vendors
in /usr/lib?

And somehow I can't really see the advantage of a 64bit enabled
mp3-player either .. or volume-control. Emacs perhaps? [(ducks)]

With Gimp - having many huge layers in flight - I can see the advantage
of 64bit. With most other applications though, it is not so clear. 

> - For a 64 bit desktop system please ensure the 32 bit libraries for
> alsa, jack and pulseaudio are installed by default.
> 


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Loki Davison]

On 8/10/09, Patrick Shirkey  wrote:
>
> On 08/10/2009 05:14 PM, Jens M Andreasen wrote:
>> On Mon, 2009-08-10 at 15:22 +1000, Patrick Shirkey wrote:
>>
>>
>>> "PAE is required for NX support, and furthermore enables larger
>>> swapspace support for non-overcommit purposes. It has the cost of more
>>> pagetable lookup overhead, and also consumes more pagetable space per
>>> process."
>>>
>>> That suggests to me a similar situation to a win modem or auto
>>> resampling.
>>>
>>>
>>
>> Why? The sentences above do not specify what is compared and only
>> handwavingly suggests a cost of "more"  ... Mind you, 64bit pointers
>> crawling all over the place ain't free either.
>>
>>
>
> Simply because they don't specify the real world cost of using the method.
>
>
>>> - Should this be a recommended method coming from LAD?
>>>
>>>
>>
>> Rather than suggesting something that is defunkt by default, yes.
>>
>>
>
> I Absolutely agree. I will add that as it's coming from LAD it should
> ideally be the most efficient and future proof option with fallback for
> situations where it is not possible to implement the complete
> recommendation.
>
> I consider this approach part of the fallback.
>
>
>>> BTW, it would be interesting to get some real world feedback from
>>> anyone who has this enabled already on a 32 bit platform.
>>>
>>>
>>
>> This would most likely be enabled by default for anybody who has
>> installed a 32bit distro on a machine with 8GB memory.
>>
>>
>>
>
> Hmmm, I wonder how many people are in that situation?
>
> IIUC the only way to get 8GB or RAM onto a normal mobo is with a quad
> core 64 bit system. Are you suggesting that there are a lot of people
> who have one of these beasts who are running 32 bit OS on it?
>
> I know I'm not.
>
> Just out of interest I wonder if Fons would be willing to run 32 bit on
> the new system  he is looking at purchasing?
>
> Can we get a show of hands? Is anyone running 32 bit with 8Gb of memory?
> How about 64 bit with the same specs?
>
>

I'm running 64 bit, quad core with 8 gb of ram. Systems like this cost
USD600 here now. :) I play a quite a few games as well as doing
recording with it ;)

Loki
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Nick Copeland]

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.



- 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.
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

Re: [LAD] linux audio standards base?

[Patrick Shirkey]

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. 

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Ralf Mardorf]

Arnold Krille wrote:
> On Sunday 09 August 2009 14:12:56 Kjetil S. Matheussen wrote:
>   
>> No, as I said, the solution is very simple: Don't install a 64 bit OS.
>> That's what's causing your problems, apparently.
>> 
>
> Helloo! Please leave the 20th century where it belongs. Nowadays 64bit are 
> normal with new computers and its a terrible waste not to use them (reminds 
> me 
> of "640kB should be enough for everybody").
>
> If the combination of 64bit and 32bit-binary-only apps is broken, its the 
> developers or the distributions task to fix it. And the users task to point 
> out 
> the problems and demand the fix.
>
> Looking away by only using 32bits is _not_ the solution. And please stop 
> telling that "solution" to other people. We are in the 21th century after 
> all...
>
> Arnold

Wow :)

full ACK. Even if I prefer Debian based distros, I mentioned that Suse 
is a little bit smarter, e.g. the proprietary LightScribe 32-bit stuff 
can be installed to Suse 64-bit, but not to Debian 64-bit.

Ralf
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] linux audio standards base?

[Ralf Mardorf]

*???* Pulseaudio, 64-bit and JACK are a strange issue. I'm using 64-bit, 
the proprietary flash for 64-bit and I can run JACK, use audio software, 
e.g. Qtractor and at the same time watch YouTube etc.. Pulseaudio is not 
installed. Am I missing something, because I don't have Pulseaudio?

Ralf

Patrick Shirkey wrote:
>
> 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. 
>> 
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev