Re: [linux-audio-dev] [OT] linux audio on PPCi

2003-12-01 Thread Richard Spindler
On Thu, 2003-11-27 at 11:42, [EMAIL PROTECTED] wrote: I am contemplating buying a laptop of some sort, to develop on. I was wondering how many of you are using an x86 laptop and how many are using a ppc laptop :) I own an Apple iBook running Yellow Dog Linux, but I do not run a patched

Re: [linux-audio-dev] another kernel patch?

2003-12-01 Thread Roger Larsson
On Sunday 30 November 2003 05.03, Jack O'Quin wrote: Roger Larsson [EMAIL PROTECTED] writes: That's right. But, Paul and I have been working closely with this and don't have much faith in the correctness of the 2.4 scheduler. Have you told kernel developers about this? This can be

Re: [linux-audio-dev] [OT] linux audio on PPCi

2003-12-01 Thread CK
I read: I think this an urban myth, the Nvidia drivers may be proprietary but they are well functioning. I think this is a pretty rural comment, there is more than x86, where are the nvidia binaries for 2.6, and personally I really don't feel like loading a binary only module. regards, x

Re: [linux-audio-dev] [OT] linux audio on PPCi

2003-12-01 Thread Robert Jonsson
Hi, CK wrote: I read: I think this an urban myth, the Nvidia drivers may be proprietary but they are well functioning. I think this is a pretty rural comment, there is more than x86, where are the nvidia binaries for 2.6, and personally I really don't feel like loading a binary only module.

Re: [linux-audio-dev] [OT] linux audio on PPCi

2003-12-01 Thread CK
I read: These are also valid arguments but they have nothing to do with the stability and quality of the nvidia drivers which is what I intended to comment about. right, sorry this was sort of pre-coffee cheers, x -- [EMAIL PROTECTED] Postmodernism is german romanticism with better

Re: [linux-audio-dev] [OT] linux audio on PPCi

2003-12-01 Thread Steve Harris
On Thu, Nov 27, 2003 at 11:42:16 +0100, [EMAIL PROTECTED] wrote: I am contemplating buying a laptop of some sort, to develop on. I was wondering how many of you are using an x86 laptop and how many are using a ppc laptop :) It looks to me as if Apples laptops are rock solid and don't suffer

Re: [linux-audio-dev] [OT] linux audio on PPCi

2003-12-01 Thread Niklas Werner
Am Donnerstag, 27. November 2003 11:42 schrieb [EMAIL PROTECTED]: I am contemplating buying a laptop of some sort, to develop on. I was wondering how many of you are using an x86 laptop and how many are using a ppc laptop :in I am using a Powerbook G3 500 and a G4 1.25 both with gentoo. They

Re: [linux-audio-dev] [OT] linux audio on PPCi

2003-12-01 Thread vincent . touquet
On Mon, Dec 01, 2003 at 10:12:24AM +, Steve Harris wrote: I guess the more of us who buy them the quicker the endianness problems will be fixed, ppc-linux-audio-user? :) :) I was thinking along the same lines ;) v

Re: [linux-audio-dev] another kernel patch?

2003-12-01 Thread Takashi Iwai
At 29 Nov 2003 22:03:09 -0600, Jack O'Quin wrote: Roger Larsson [EMAIL PROTECTED] writes: That's right. But, Paul and I have been working closely with this and don't have much faith in the correctness of the 2.4 scheduler. Have you told kernel developers about this? This can be

Re: [linux-audio-dev] new linux audio hardware company

2003-12-01 Thread Michael Ost
Maybe I can answer that, since I work for Muse. I just grep'd the web pages and didn't find 'license free'. Where did you see that? I am a bit mystified by that statement and would like to look into it. Some licenses I can think of off hand that we are using are GPL, LGPL, FreeBSD, and the

Re: [linux-audio-dev] new linux audio hardware company

2003-12-01 Thread Tim Orford
Maybe I can answer that, since I work for Muse. I just grep'd the web pages and didn't find 'license free'. Where did you see that? I am a bit mystified by that statement and would like to look into it. its in the mouse-over text for 'museLINUX' in the flash movie. regards -- Tim Orford

Re: [linux-audio-dev] another kernel patch?

2003-12-01 Thread Jack O'Quin
Takashi Iwai [EMAIL PROTECTED] writes: Jack O'Quin wrote: But, I have no reason to believe that it works correctly, and I suspect that it probably does not. as Roger pointed, the O(1) scheduler does quite simple tasks for RT processes. it *should* work. if it deson't work, it's a bug

Re: [linux-audio-dev] new linux audio hardware company

2003-12-01 Thread Michael Ost
Thanks for the debugging. We are looking into it and will correct it. - mo On Mon, 2003-12-01 at 13:02, Tim Orford wrote: Maybe I can answer that, since I work for Muse. I just grep'd the web pages and didn't find 'license free'. Where did you see that? I am a bit mystified by that

[linux-audio-dev] mini Review: Re: [Jackit-devel] latest CVS commit

2003-12-01 Thread Roger Larsson
On Monday 01 December 2003 20.48, Paul Davis wrote: i'd appreciate test reports ASAP, so that out trusty release technician (the very wonderful taybin rutkin) can get a new release out in the near future. alsa_driver.c driver-period_usecs = (jack_time_t) floor

Re: [linux-audio-dev] another kernel patch?

2003-12-01 Thread Paul Davis
Roger Larsson [EMAIL PROTECTED] writes: But it is still a way to see that no client burns cycles where it should not - jackd would not start (or stop). And you _can_ get fewer context switches, but only if some client burns extra cycles. Compare: With jackd as highest priority: Context

[linux-audio-dev] Re: mini Review: Re: [Jackit-devel] latest CVS commit

2003-12-01 Thread Paul Davis
On Monday 01 December 2003 20.48, Paul Davis wrote: i'd appreciate test reports ASAP, so that out trusty release technician (the very wonderful taybin rutkin) can get a new release out in the near future. alsa_driver.c driver-period_usecs =3D (jack_time_t) floor

Re: [linux-audio-dev] Re: mini Review: Re: [Jackit-devel] latest CVS commit

2003-12-01 Thread Jack O'Quin
Paul Davis [EMAIL PROTECTED] writes: but yes, you are right, it is dangerous. we should probably sleep for max (1msec, period_msecs). agree? I agree. Since the exact duration of the timeout probably doesn't matter that much, I am experiementing with just adding one to period_msecs. --