On 08/09/2009 08:12 PM, Kjetil S. Matheussen wrote: 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.

On 08/09/2009 10:12 PM, Kjetil S. Matheussen wrote: Oh, I get you now. So are you advocating that the official recommendation of LAD is not to use a 64 bit system?

On 08/09/2009 10:35 PM, Kjetil S. Matheussen wrote: 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(a)lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

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

On Sun, 2009-08-09 at 16:31 +0200, Arnold Krille wrote: 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?

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 was....sufficient. 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<arnold(a)arnoldarts.de> wrote: -- www.openoctave.org midi-subscribe(a)openoctave.org development-subscribe(a)openoctave.org

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.

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

On Sunday 09 August 2009 23:47:17 Fons Adriaensen wrote: Ah, okay. So aeolus was a bad example...

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

On 08/11/2009 08:59 AM, Nick Copeland wrote: 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>

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

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

On 08/10/2009 05:14 PM, Jens M Andreasen wrote: Simply because they don't specify the real world cost of using the method. 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. 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?