Low Latency vs. Real Time Kernel
by Brian Monroe
I've been spending a lot of time on the #opensourcemusicians channel
talking to Ubuntu Studio users about their kernel and latency times they're
getting. Seems like most of them are using g a stock kernel with the
preemptive option enabled and they are getting great latency results
(2ms)while utilizing the @audio group on their user. I ended up compiling
my own low latency kernel and I haven't had any issues with it yet. If this
is what we are missing for the spin I'd be happy to maintain packaging for
the kernel. I know ccrma has been behind a few kernel releases.
I saw the instructions for adding the real time patch for a tick less
kernel and from what I can tell it wouldn't be hard to get that rolling as
well.
I'm not entirely sure what ccrma does differently with their kernels
compared to other Linux users, and I'm still a bit of a noob so I could be
off base with this, but I would reason that we should be able to just
utilize the same settings to archive similar performance enhancements.
I thought I read that ccrma uses a unique scheduler, but if we could get a
2ms latency time without it, the point may be moot.
8 years, 10 months
audacity - audio editor - testers requested
by Development discussions related to Fedora
Hi,
Following up on a scratch build from two weeks ago, the audacity project
[1] is now at release candidate 1 for audacity 2.0.0 [2], and is
expecting to release in another 2 weeks.
I've built packages for Fedora devel [3] and RPM Fusion 16 [4].
I would welcome any help you can give in testing either package, as
preparation for release of v2.0.0, and providing packages for Fedora users.
In terms of the testing, while I think a fairly random approach is
useful, think about a task you would like to achieve with audacity, and
follow through with it, to see that it succeeds.
For problems, please create bugs, or reply to this message with a
subject indicating the issue.
Rather than a straight, "works for me", please indicate any
functions/menus you did use, so that others might test different
functionality.
For mp3/ffmpeg file format support, use the version audacity-freeworld
from rpmfusion buildsys instead.
[1] http://code.google.com/p/audacity/
[2] http://code.google.com/p/audacity/downloads/list
[3] http://koji.fedoraproject.org/koji/taskinfo?taskID=3802444
[4]
<http://buildsys.rpmfusion.org/plague-results/fedora-16-rpmfusion_free/aud...>
11 years, 7 months
Re: [Fedora-music-list] Call to arms - Fedora Audio Spin
by Philip Rhoades
Christopher,
On 2012-02-22 17:00, Christopher R. Antila wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/21/2012 03:51 PM, Brendan Jones wrote:
>> On 02/21/2012 09:07 PM, Kyrian wrote:
>>> ...
>>>
>>> - Then I think, ah, wrong kernel, and pulseaudio? But that could
>>> be grouped too, no? Have, say, Jack and have it conflict with
>>> pulseaudio somehow?
>>
>> Pulseaudio is proving to be a pain. Its now an implicit dependency
>> of the default desktop (GNOME) which is unfortunate. Having said
>> all that, I think its a great piece of software, but creates
>> unnecessary complications when all you want to do is
>> create/produce and edit music. There are some applications which
>> refuse to play with anything else now (skype anyone?) that mean
>> people like me have no choice but to coexist with it. I'm still not
>> happy with my setup - other users on this list have also posted
>> their solutions [2]. I think we should aim to ship a
>> pulseaudio-less solution. This means we need to decide on a desktop
>> that's not Gnome - of course that won't make everyone happy, but if
>> we have the comps group like you suggest, those gnome users can
>> still pull in the audio packages with ease.
>
> Something about this seems off.
>
> I remember when it used to be the case that audio cards generally
> wouldn't work by default in Linux. Slowly, eventually, PulseAudio
> solved that. If we remove PulseAudio, we're forcing our users to "go
> it alone." Now, I understand that PulseAudio isn't ideal for audio
> creation software--that's why it uses JACK--but we don't want to
> throw
> away everything that PulseAudio gained. And surely we want to allow
> people to use GNOME if they want. And Skype. Otherwise we risk
> running
> into a situation where people enjoy using the Fedora Audio Spin for
> audio-creation tasks, but can't stand it for anything else.
That hasn't been my experience - after much pain over the last few
years with audio, the first thing I do is remove PA and just use ALSA .
. but I am an audio guru wannabe . .
Regards,
Phil.
--
Philip Rhoades
GPO Box 3411
Sydney NSW 2001
Australia
E-mail: phil(a)pricom.com.au
--
Philip Rhoades
GPO Box 3411
Sydney NSW 2001
Australia
E-mail: phil(a)pricom.com.au
11 years, 7 months
Re: [Fedora-music-list] Call to arms - Fedora Audio Spin
by Kyrian
Just been taking a metaphorical chainsaw to my inbox and got through to
the Fedora Music list at long last.
I've packaged up some bits and bobs and assisted with Fedora myself, for
better or for worse. Anyway, this thread makes me think a couple of
things that I'd like to throw in for the masses (nor not, as the case
may be) to chew over.
- Couldn't this lot be done as a yum 'Group' or several? With that then
incorporated into the standard installer environment?
- Then I think, ah, wrong kernel, and pulseaudio? But that could be
grouped too, no? Have, say, Jack and have it conflict with pulseaudio
somehow?
- Then it all sounds a bit complicated, and I can't help think that
maybe a respin is a valid and sane way forward.
- But still, it might be nice to give the non-pro users a leg-up to that
sort of stuff with package groups in Yum anyway? Surely you don't need
an RT kernel unless you're really hammering at the audio?
- Having better documentation would be really good, and I've noted the
"Musicians Guide" on my travels, which I fully intend to real real soon
now(tm).
- Every person who's into pro audio that I mention about Linux audio
says "ah, but will it accomodate my XYZ plugins/filters from a.n.other
windows app"? As far as I know the answer is usually "yes", but I hope
that's documented in wherever the docs are.
I'll gladly put in such time as I can find to make this happen, and if
necessary to get it documented as well, because I want to start using
all my kit properly through Linux, with the minimum of fuss (there was a
lot of fuss the last time I had a go, in spite of PlanetCCRMA and
other's best efforts...), help other people at the same time, but
perhaps mainly, get some distractions from my day job which involves
Linux too.
Another thing it would be nice to have is a way to use my laptop running
Linux for dj-ing if I'm feeling extremely lazy on a given night (I'm not
a laptop DJ when I do so, but others are, and, hell, CD's are heavy,
physically as well as at times musically), but I could not find a
suitable app for that. Rhythmbox has a cross-fade feature, but it's a
bit "brute force" and not very nuanced.
If this helps, or provokes discussion in any way, then that's great, and
if someone can help me with any of the above questions, that's perhaps
even better.
Yours,
Kev "Kyrian" Green.
--
Kev "Kyrian" Green. WWW: http://kyrian.ore.org/
Linux Security + Hosting + Admin/LAMP Coder @ http://www.orenet.co.uk/
When I spit in the eye of the gods, then I will smile
11 years, 7 months
spin-kickstarts/fedora-music-creation-base.ks
by Brendan Jones
spin-kickstarts/fedora-music-creation-base.ks | 110 ++++++++++++++++++++++++++
1 file changed, 110 insertions(+)
New commits:
commit d14887a7fcc5de5315631730b4039413ee1c39ef
Author: Brendan Jones <brendan.jones.it(a)gmail.com>
Date: Wed Feb 22 13:51:35 2012 +0100
Default package suggestions
diff --git a/spin-kickstarts/fedora-music-creation-base.ks b/spin-kickstarts/fedora-music-creation-base.ks
new file mode 100644
index 0000000..617cac8
--- /dev/null
+++ b/spin-kickstarts/fedora-music-creation-base.ks
@@ -0,0 +1,110 @@
+# fedora-music-creation-base.ks
+#
+# Description:
+# - Simply a suggested package selection for music creation. This is
+# not an exhaustive list, but could be used as a base to create a
+# group entry for the comps.xml file at some point.
+#
+# Maintainer(s):
+# - Brendan Jones <bsjones(a)fedoraproject.org>
+#
+# Changelog
+# ---------
+# Wed Feb 22 2012 Brendan Jones <bsjones(a)fedoraproject.org>
+# - created
+
+
+%packages
+
+# fedora audio
+multimedia-menus
+
+# alsa / jack / transport
+jack-audio-connection-kit
+qjackctl
+jackctlmmc
+a2jmidid
+alsa-firmware
+alsa-plugins-jack
+alsa-plugins-pulseaudio
+alsa-tools
+alsa-tools-firmware
+alsa-utils
+alsamixergui
+
+# midi
+arpage
+qmidiarp
+timidity++
+seq24
+
+# DAWs
+ardour
+rosegarden
+muse
+
+# notation / editors
+frescobaldi
+swami
+lilypond
+audacity
+
+# synths / samplers
+zynaddsubfx
+fluidsynth
+qsynth
+#ams
+bristol
+hydrogen
+
+# guitar effects
+guitarix
+rakarrack
+
+# samplers /
+sooperlooper
+audacious
+
+# plugins
+calf
+
+lv2-EQ10Q-plugins
+lv2-abGate
+lv2-avw-plugins
+lv2-c++-tools
+lv2-fil-plugins
+lv2-invada-plugins
+lv2-kn0ck0ut
+lv2-ll-plugins
+lv2-mdaEPiano
+lv2-swh-plugins
+lv2-ui
+lv2-vocoder-plugins
+lv2-zynadd-plugins
+lv2core
+lv2dynparam
+slv2
+
+ladspa
+ladspa-amb-plugins
+ladspa-autotalent-plugins
+ladspa-blop-plugins
+#ladspa-cap-plugins
+ladspa-cmt-plugins
+ladspa-fil-plugins
+ladspa-mcp-plugins
+ladspa-rev-plugins
+ladspa-swh-plugins
+ladspa-tap-plugins
+ladspa-vco-plugins
+
+dssi
+#dssi-vst
+fluidsynth-dssi
+hexter-dssi
+nekobee-dssi
+whysynth-dssi
+xsynth-dssi
+
+%end
+
11 years, 7 months
Call to arms - Fedora Audio Spin
by Brendan Jones
Hi all,
Traditionally Fedora has been known to walk the bleeding edge in free
and open source software development but for some reason this has never
been realised in the realms of pro-audio/music creation.
Fedora has never really attracted the support of the audio development
community, and as a direct result has only flagging support from audio
users, enthusiasts and professionals alike.
I think there are a number of reasons for this:
1) Strict packaging and licensing guidelines,
2) relatively short release support cycles
3) the absence of an stock RT kernel
4) the effort required to tailor an installation for audio use
Distributions like Debian/Ubuntu/Arch (and others like AVLinux) have
garnered strong support because they in some way address all of these
issues. Fedora however...
1) and 2) we can't change. In fact at the end of the day these
strengthen the distribution by making the packages we ship more robust
and closer to upstream. It also demands a certain amount of love to
ensure that updates/ABI bumps/breakages are dealt with decisively and
swiftly. It also means that audio developers are more unlikely to
maintain their own packages in Fedora (we need more maintainers)
3) I can't see happening any time soon. The kernel team maintain so many
out of tree patches already that I don't think they really have the time
nor desire to maintain the realtime kernel as well. I don't see this as
a problem - recent kernels have incorporated much of the the rt kernel
patches of old and should satisfy most users. For those with more
stringent requirements can rely on the CCRMA patched kernels
4) is where I think an audio spin comes into play. If we can
collate/automate all of the steps involved in setting up Fedora for
audio production we will attract both users and maintainers alike
alleviating the problems caused by 1 and 2.
I'm proposing to formally revive the past Fedora Audio Spin / Music
Creation efforts of a couple of years ago in time for an F18 Audio spin
release. This means we have one whole release cycle to get all of the
packages we require into stable so they can be available for Live
composes for the F18 release cycle.
Apart from packaging efforts, the last few weeks for me has been an
information gathering exercise. More on this soon, but briefly, the
current to do list is:
- pulling in all of the must have packages from CCRMA
- determining the package list
- packaging the Fedora Musician's guide
- repackaging/patching rpmfusion packages for Fedora (qtractor and
others if required)
- developing sane RT priorities for the stock kernels (threadirqs)
- consensus on distribution media, default desktop/supported desktops
- default systemd enabled services
- themes and artwork
- resubmit the Spin proposal for F18
If you want to contribute, here's how:
- become a contributor/get a FAS account [1] and join the
music-creation group
- help maintain the audio creation wiki's (formalize the to do
list)[2][3] - this is really out of date. Many packages have been
orphaned or are already in Fedora. Needs to be brought in line
with the package database [5]. I'm not convinced that this page
really needs to be so detailed. Wish lsit is probably the most
important
- register your interest in the contributor section of the audio
spin wiki [3]
- help test new packages - I will be listing all upcoming changes on
this list and I encourage other package maintainers to do the same
[3]
- become a tester or packager of audio packages [4][5]
- help test the new spins as we make them available.
- join Chris in his documentation efforts [7]
- volunteer desktop artwork
- and most importantly, voice your opinion on how this project
should be realized! Choice of media/desktop/applications
/configuration etc. More proposals on this coming soon.
Packaging the software and building the media constitutes less than a
quarter of the effort required here. What we need most is strong
community support so please respond to this email if you are interested!
Lets do it
Brendan
[1] https://admin.fedoraproject.org/accounts/
[2] http://fedoraproject.org/wiki/Audio_Creation
[3] http://fedoraproject.org/wiki/AudioCreationSpinDevelopment
[4] http://fedoraproject.org/wiki/QA
[5] http://fedoraproject.org/wiki/Join_the_package_collection_maintainers
[6] https://admin.fedoraproject.org/pkgdb/
[7]
http://docs.fedoraproject.org/en-US/Fedora/15/html/Musicians_Guide/index....
11 years, 7 months
Package and Revise the Musicians' Guide
by Christopher Antila
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Greetings to the list:
==== Packaging ====
The Musicians' Guide has been published since Fedora 14. I think, when
Brendan says he wants to "package" it, he wants an RPM version that
users can download and access without an active Internet connection.
Nobody has done this yet.
For most of the Guides, this isn't particularly useful. That's why (I
think) only the Release Notes are packaged. Theoretically, everybody
should read the Release Notes. For most of the other documentation,
it's not as useful to have an RPM package. I'm not even sure whether
the Release Notes are packaged any more.
The Musicians' Guide is a little different. There are a lot of extra
media files that go along with the tutorial exercises, and it would be
handy for users to download all the media files at once. I'm not sure
of the best way to deliver these files--maybe even separately from the
documentation, or separately from each other--but RPM packages would
be useful.
I would really appreciate somebody else's help in taking care of the
packaging issue, so I can spend my time on the list below.
==== Revising ====
These have always been problems, but they're more prominent if an
Audio Spin or RPM package draws attention to the documentation.
1.) Official Fedora documentation shouldn't recommend and provide
instructions for installing non-Fedora package repositories. There's a
chapter about the real-time kernel and the Planet CCRMA repository.
This is also an issue because it involves/recommends a lot of manual
tweaking that tends to break between releases. I'm fine with just
leaving this, but it must be tested.
2.) Related to the previous point, Qtractor and SuperCollider are only
available from the RPMFusion and Planet CCRMA repositories,
respectively. Depending on what we do about point (1), we could just
remove those chapters until the Qtractor and SuperCollider make it
into the official repositories. Ideally, only the rt-kernel would live
at Planet CCRMA (as far as "things in the Musicians' Guide" go).
3.) I didn't finish some of the tutorials, so they don't have examples
of the completed project. I want to rewrite a few of those with new
content anyway. The Ardour tutorial is particularly questionable; it
doesn't have a completed version *and* I don't know if the setup
process even works for other people.
4.) The Qtractor tutorial relies on a copyrighted sound recording that
isn't freely available on the Internet. It's also not included. Easy
fix: adjust the tutorial to use a recording, even of the same music,
that we can redistribute.
5.) Here's the best one! The Audacity tutorial is made with fragments
of a copyrighted sound recording that *are* included. My understanding
of copyright law at the time suggested it would be okay, because the
fragments are short, because it is impossible to reconstruct the
original content from the fragments, and because it is intended merely
for private, educational purposes (learning how to use Audacity).
I have since realized that, even though these factors may apply, it
won't necessarily stop an organization from filing a lawsuit.
Packaging these fragments makes it worse, and including them on live
media for a Spin makes it worse still. This point also has an easy
solution: start with fragments that we can redistribute. We wouldn't
even have to rewrite the tutorial... just do all of the same things
with the new fragments.
6.) There's a "to-do" list in the comments at the bottom of the
Revision_History.xml file of the Guide's repository.[0]
7.) There are also a few issues on Bugzilla, including some patches
that should be incorporated.
8.) Then of course I complain about my writing quality. Everything
needs to be copy-edited.
In short, other contributors' help would be greatly appreciated. Let's
get crackin'!
Christopher.
[0] https://fedorahosted.org/musicians-guide/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBAgAGBQJPQwrRAAoJEInCktGVqZ8V71EH/RKhFLKMRMkDXUqWlt6EVQhN
UdV7qFWMp3tMkztLFt+Si7LcxVtAi2ajlGFEj0tx4YY/ra/SQNvXx1NgB0RLoC49
wSVd9WK9uX/yGKk96/hfjwg+WtxXkDz03+rXJDV6Owry1NdzjAMUlqMCzqbs1unU
SpNAOSM25EqUaaCn3T8yDkRoqaiZUcFlznIndx1O4A2CD63Ktav9IL16Z4MIX3uj
BHKcprtB9LDqRtIKD8BOaOqYb10AFjdWzKMIA02ND3kumKh/BCCPE9xtVj6mQaNo
bueI6dlAjjPJf5sNEnaKBDgmt7R71A94SWXNOw8TsRKO62tYg249SQ8ZrdXU880=
=6ubV
-----END PGP SIGNATURE-----
11 years, 7 months
