19 Aug
2008
19 Aug
'08
3:41 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hey guys,
After bleeding-edge linux-tuning and some br0ken 2.6.25's what are
candidates for a stable audio setup?
I'm currently running "2.6.24.7-rt17-pure #3 SMP PREEMPT RT" from
http://guests.goto10.org/~krgn/files/ which seems great for day-to-day
work and sound-production. runs for 3 days now, few suspend to RAM, no
reboot since, and worked out of the box.
It passes the mplayer via wifi-NFS and jconv test without a single xrun
at 256 frames/period, 3period @ 48Ksps with HDA-intel/PCI and UA-25+USB.
JACK (ardour, rosegarden, etc) works as usual.. including
gnome,iceweasel+flash and whatever - gonna test firewire soon.
I'm considering to make this my new default; maybe recompile it with
few minor changes (optimized for MCORE2, no generic i386) - It also
seems to be a bit more power-hungry that 2.6.24.3-rt3 - hard to tell
since former kernel does support `powertop`:
(No detailed statistics available; please enable the CONFIG_TIMER_STATS
kernel options - This option is located in the Kernel Debugging section
of menuconfig which is CONFIG_DEBUG_KERNEL=y in the config file)
Just for reference it's a X60s, running a
debian-lenny/sid/debian-multimedia/64studio distro mix..
I changed the USB-irq in the bios but I didn't do much besides using
rtirq.deb from 64studio and usual limits.conf with debian jackd
0.109.2. - I still have `dev.rtc.max-user-freq=8192` in sysctl.conf -
but I don't think it is being used with HPET.
What kernel/setup/system are you guys *tuning* for work, recording,
production and/or live performance.
robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkiqXOgACgkQeVUk8U+VK0LsLgCfa61CKCKoS/xFhaBxWzZRfS9A
fsUAn1ybxfn/P7fjiEr4WLijOXpcVM8r
=CH0l
-----END PGP SIGNATURE-----
19 Aug
19 Aug
1:36 p.m.
Robin Gareus said :
I'm currently running "2.6.24.7-rt17-pure #3
SMP PREEMPT RT" from
http://guests.goto10.org/~krgn/files/ which seems great for day-to-day
work and sound-production. runs for 3 days now, few suspend to RAM, no
reboot since, and worked out of the box.
great.
It passes the mplayer via wifi-NFS and jconv test
without a single xrun
at 256 frames/period, 3period @ 48Ksps with HDA-intel/PCI and UA-25+USB.
JACK (ardour, rosegarden, etc) works as usual.. including
gnome,iceweasel+flash and whatever - gonna test firewire soon.
Thanks for helping testing on this.
What kernel/setup/system are you guys *tuning* for
work, recording,
production and/or live performance.
personnaly p:d on a x22 and a x61 + a hdsp multiface with the current
pure kernel
http://code.goto10.org/projects/puredyne/browser/live/kernel/2.6.23
and will switch to karsten's 2.6.24.7-rt17-pure soonish.
And this will also be the default p:d kernel for the next liveCD
release, as it seems 25 and 26 are too dodgy at the moment.
If all goes well, we could use this kernel config as a basis for a
common effort to build a LAT kernel, or at least start mirror some
config on the LAT git. (any chance for mercurial instead of git?)
a.
20 Aug
20 Aug
7:06 a.m.
Hi Aymeric,
and will switch to karsten's 2.6.24.7-rt17-pure
soonish.
And this will also be the default p:d kernel for the next liveCD
release, as it seems 25 and 26 are too dodgy at the moment.
If all goes well, we could use this kernel config as a basis for a
common effort to build a LAT kernel
I'm very much in favour of that, because it means we can bring our
combined resources and communities to the quality assurance process.
Having a reference implementation of the kernel might also help us to
work with audio hardware manufacturers, because it would enable us to be
definitive about whether a particular piece of hardware was supported or
not, and apply fixes where required. For example, we used to be able to
say that M Audio devices were generally supported, but the newest
hardware revision of the Delta range is problematic with current ALSA,
and the new M Audio multichannel USB 2.0 interfaces are not class
compliant either.
Cheers!
Daniel
21 Aug
21 Aug
11:52 a.m.
Hey Daniel,
exactly
and will
switch to karsten's 2.6.24.7-rt17-pure soonish. And this will
also be the default p:d kernel for the next liveCD
release, as it seems 25 and 26 are too dodgy at the moment.
If all goes well, we could use this kernel config as a basis for a
common effort to build a LAT kernel
I'm very much in favour of that, because it means we can bring our
combined resources and communities to the quality assurance process. Having a reference implementation of the kernel might
also help us to
work with audio hardware manufacturers, because it would enable us to be
definitive about whether a particular piece of hardware was supported or
not, and apply fixes where required. For example, we used to be able to
say that M Audio devices were generally supported, but the newest
hardware revision of the Delta range is problematic with current ALSA,
and the new M Audio multichannel USB 2.0 interfaces are not class
compliant either.
Yes, that's a good point.
Also from the user side, we have so many common needs and overlapping
interests, I'm convinced we can all work toward a unified audio/video kernel
config (or set of configs) and provide builds for different architectures
and distros.
This would simplify a lot things, and combine indeed our too many local and
isolated efforts.
a.
2:41 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
aymeric mansoux wrote:
Hey Daniel,
exactly
sounds good to me. How are we organizing this collaboration? What is the
common denominator for tools and infrastructure? Do we want to agree on
a common file-structure for patches and .config files? Are you going to
push or is LAO going to pull data?
I propose we start minimalistic and expand when needed ;) With this
email-list at the center, we do not need to (and should not) centralize
services at linuxaudio.org and retain freedom of distributors. LAO can
become a portal, meta-platform and hub. *YOU* provide any service you
feel is appropriate; if necessary LAO can provide hosting or backup.
more concrete: I think we should follow the kernel.org sign-off strategy
and git example. There can have multiple projects (alike
http://git.kernel.org) and a shared reference repository.
Here are two starting points: http://wiki.linuxaudio.org/wiki/kernel/
http://git.linuxaudio.org/ that can be expanded after brainstorm and
testing. For write access: PM a ssh-key and project-name to git AT
linuxaudio DOT org until we have a more formal procedure.
Are there intention for a [regular] /meeting/ (IRC)?
#robin
and will
switch to karsten's 2.6.24.7-rt17-pure soonish. And this will
also be the default p:d kernel for the next liveCD
release, as it seems 25 and 26 are too dodgy at the moment.
If all goes well, we could use this kernel config as a basis for a
common effort to build a LAT kernel
I'm very much in favour of that, because
it means we can bring our
combined resources and communities to the quality assurance process. Having a reference implementation of the kernel
might also help us to
work with audio hardware manufacturers, because it would enable us to be
definitive about whether a particular piece of hardware was supported or
not, and apply fixes where required. For example, we used to be able to
say that M Audio devices were generally supported, but the newest
hardware revision of the Delta range is problematic with current ALSA,
and the new M Audio multichannel USB 2.0 interfaces are not class
compliant either.
Yes, that's a good point.
Also from the user side, we have so many common needs and overlapping
interests, I'm convinced we can all work toward a unified audio/video kernel
config (or set of configs) and provide builds for different architectures
and distros.
This would simplify a lot things, and combine indeed our too many local and
isolated efforts. -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkitmqcACgkQeVUk8U+VK0IbIACgh4A3uD9wqzahN5D0ihc4wVi1
Nm8AoKUEaLpaueRj2g3hEXqiglmLDv0l
=YgSk
-----END PGP SIGNATURE-----
22 Aug
22 Aug
1:51 p.m.
Hi Robin,
more concrete: I think we should follow the kernel.org
sign-off strategy
and git example.
Sounds good - linuxaudio.org as the authoritative source? :-)
Here are two starting points:
http://wiki.linuxaudio.org/wiki/kernel/
http://git.linuxaudio.org/ that can be expanded after brainstorm and
testing.
Thanks for putting those together.
Are there intention for a [regular] /meeting/ (IRC)?
I don't think we need that yet, unless a formal team is organised. I
could be wrong about that though ;-)
Cheers!
Daniel
2:33 p.m.
Daniel James said :
I agree, let's start it slowly and see how it goes.
Concerning the directory structure, we use that for p:d:
http://code.goto10.org/projects/puredyne/browser/live/kernel
a rather simple
kernel version
`- config
`- patches
maybe good enough for now?
in terms of who is pushing what to who, I would not mind dropping the
kernel folder we have on our SVN and only work from one type of repos.
So, that means we would push stuff directly to the/a LAT git.
It doesn't make much sense to maintain 2 different type of repos for
that (SVN and git). What do you think Karsten? It's gonna be a pain to
move data from p:d SVN to a LAT git and back everytime we have a new
config commited I think.
If we need non LAT generic config, we can always have distro
specific config files in another LAT git or in a subfolder, etc ...
We might have to experiment for a little while anyway, until we have
some workflow and structure that everyone is happy with :)
a.
Are there
intention for a [regular] /meeting/ (IRC)?
I don't think we need that yet, unless a formal team is organised. I
could be wrong about that though ;-)
Cheers!
Daniel
23 Aug
23 Aug
9:20 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
aymeric mansoux wrote:
Daniel James said :
I agree, let's start it slowly and see how it goes.
Concerning the directory structure, we use that for p:d:
http://code.goto10.org/projects/puredyne/browser/live/kernel
I like that trac ;)
Are there
intention for a [regular] /meeting/ (IRC)?
I don't think we need that yet,
unless a formal team is organised. I
could be wrong about that though ;-) a rather simple
kernel version
`- config
`- patches
maybe good enough for now?
yes, then this will become a /project/ by itself (not related to
kernel-git) and we may want add one folder depth:
VERSION -> MINORVERSION-<VENDOR> -> <files>
eg. 2.6.26 -> 2.6.26.2-dyne -> config & patches
in terms of who is pushing what to who, I would not
mind dropping the
kernel folder we have on our SVN and only work from one type of repos.
So, that means we would push stuff directly to the/a LAT git.
It doesn't make much sense to maintain 2 different type of repos for
that (SVN and git). What do you think Karsten? It's gonna be a pain to
move data from p:d SVN to a LAT git and back everytime we have a new
config commited I think.
git can import export from/to svn. It's actually very easy to use both
in parallel.
If you get the upstream kernel via git; you can get a /tagged vanilla/
and configure some /git-remotes/ to just pull in patches from
linuxaudio.org or wherever. - if
http://www.google.com/search?q=git+kernel+howto is not enough, we can
collect some /quick-start/ git command-lines on the wiki.
I'm running a trac with git backend elsewhere; and may just replicate
that on linuxaudio.org. We're not actively fixing bugs, but the
ticketing system may come in handy for quality control. - Well there's
also mantis, flyspray, etc. and *this* mailing list.. We'll also need
to think how to share content and accounts for these services.
(personally I'm pushing openID, oAuth, SSH-KEYs; and WikiRPCInterface2 )
If we need non LAT generic config, we can always have
distro
specific config files in another LAT git or in a subfolder, etc ...
We might have to experiment for a little while anyway, until we have
some workflow and structure that everyone is happy with :)
sure, learning by doing..
have a nice weekend,
robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkiv8nkACgkQeVUk8U+VK0L5IACgutbhaerPnVaGeIlQip/JJoWm
8MMAn1QgMrrIxamLoeoQVWrSzU5sjFOi
=8Xla
-----END PGP SIGNATURE-----
24 Aug
24 Aug
5:36 a.m.
Hi,
|--==> On Sat, 23 Aug 2008 13:20:28 +0200, Robin Gareus <robin(a)gareus.org> said:
RG> aymeric mansoux wrote:
>Daniel James said :
>>>Are there intention for a [regular] /meeting/ (IRC)?
>>I don't think we need that yet, unless a formal team is organised. I
>>could be wrong about that though ;-)
>
>I agree, let's start it slowly and see how it goes.
>
>Concerning the directory structure, we use that for p:d:
>
>http://code.goto10.org/projects/puredyne/browser/live/kernel
RG> I like that trac ;)
Me too, and it now has git support in case we decided to go for it on
LAO :)
>a rather simple
>
>kernel version
>`- config
>`- patches
>
>maybe good enough for now?
RG> yes, then this will become a /project/ by itself (not related to
RG> kernel-git) and we may want add one folder depth:
RG> VERSION -> MINORVERSION-<VENDOR> -> <files>
RG> eg. 2.6.26 -> 2.6.26.2-dyne -> config & patches
That's a good idea IMO.
And I was say also arch-specific configs and patches:
2.6.26/2.6.26.2-dyne/config/amd64/
2.6.26/2.6.26.2-dyne/patches/amd64/
>in terms of who is pushing what to who, I would not
mind dropping the
>kernel folder we have on our SVN and only work from one type of repos.
>So, that means we would push stuff directly to the/a LAT git.
>
>It doesn't make much sense to maintain 2 different type of repos for
>that (SVN and git). What do you think Karsten? It's gonna be a pain to
>move data from p:d SVN to a LAT git and back everytime we have a new
>config commited I think.
RG> git can import export from/to svn. It's actually very easy to use both
RG> in parallel.
RG> If you get the upstream kernel via git; you can get a /tagged vanilla/
RG> and configure some /git-remotes/ to just pull in patches from
RG> linuxaudio.org or wherever. - if
RG> http://www.google.com/search?q=git+kernel+howto is not enough, we can
RG> collect some /quick-start/ git command-lines on the wiki.
RG> I'm running a trac with git backend elsewhere; and may just replicate
RG> that on linuxaudio.org. We're not actively fixing bugs, but the
RG> ticketing system may come in handy for quality control. - Well there's
RG> also mantis, flyspray, etc. and *this* mailing list.. We'll also need
RG> to think how to share content and accounts for these services.
RG> (personally I'm pushing openID, oAuth, SSH-KEYs; and WikiRPCInterface2 )
>If we need non LAT generic config, we can always
have distro
>specific config files in another LAT git or in a subfolder, etc ...
>
>We might have to experiment for a little while anyway, until we have
>some workflow and structure that everyone is happy with :)
>
I do agree, many things will become clearer on the way.
Ciao!
Free
6009
days inactive
6014
days old
linux-audio-tuning@lists.linuxaudio.org
8 comments
4 participants
participants (4)
-
aymeric mansoux -
Daniel James -
Free Ekanayaka -
Robin Gareus