On 11/26/2011 01:25 PM, Simon Lewis wrote:
Just one of those aha experiences - not sure if anyone is interested but here it is anyway...
On my fc15 x86_64 installation I built and installed pulseaudio-1.1 from the pulseaudio-1.1-3.fc17.src.rpm as found on "http://koji.fedoraproject.org/koji/".
The main reason for doing this is the better emulation of alsa in pulseaudio-1.1 compared to pulseaudio-0.9.2x.
Not only does pulseaudio run perfectly on top of jackd, but it is possible to route alsa only apps like sunvox into qtractor/ardour.
To do this I needed the four scripts listed at the bottom of this e-mail.
I used Qjackctl to run the scripts with the following entries in the options tab of the settings dialogue:
Execute script on Startup: /home//username//.scripts/pulse-jack-pre-start.sh &
Execute script after Startup: /home//username//.scripts/pulse-jack-post-start.sh & a2jmidid -e &
Execute script on Shutdown: /home//username//.scripts/pulse-jack-pre-stop.sh & killall a2jmidid &
Execute script after Shutdown: /home//username//.scripts/pulse-jack-post-stop.sh &
If anyone has a better way to start and stop a2jmidid, I would be interested.
Regards, Simon
pulse-jack-pre-start.sh _____________________ #!/bin/bash pacmd suspend true
pulse-jack-post-start.sh ______________________ #!/bin/bash pactl load-module module-jack-sink channels=2 pactl load-module module-jack-source channels=2 pacmd set-default-sink jack_out pacmd set-default-source jack_in
pulse-jack-pre-stop.sh _____________________ #!/bin/bash SINKID=$(pactl list | grep -B 1 "Name: module-jack-sink" | grep Module | sed 's/[^0-9]//g') SOURCEID=$(pactl list | grep -B 1 "Name: module-jack-source" | grep Module | sed 's/[^0-9]//g') pactl unload-module $SINKID pactl unload-module $SOURCEID sleep 5
pulse-jack-post-stop.sh ______________________ #!/bin/bash pacmd suspend false
PlanetCCRMA mailing list PlanetCCRMA@ccrma.stanford.edu http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma
Hi Simon,
Thanks for the info - awesome stuff.
Just a few questions. 1. There's no reason why these scripts cannot run with 0.9.2 right?
2. what version of jackd are you using - from the repos? or have you compiled your own with DBUS support? (jackdbus only just hit f16 recently and you are using f15)
As for your question about a2jmidid I just pkill it also.
Another script I use in f16 that I put in my path is this: (the $1 parameter is either start or stop. pre|post in yr examples). I'm a developer so most people won't be using a lot of these services anyway, but you can tailor it for your needs:
fedora16:~ $ cat ~/bin/audio_services #!/bin/bash beesu systemctl $1 nfs-idmap.service nfs-lock.service ksm.service ksmtuned.service abrtd.service cups.socket cups.service sm-client.service sendmail.service ntpd.service mysqld.service httpd.service libvirtd.service crond.service sshd.service smb.service if [ $1 == "stop" ] then beesu modprobe -r ath9k else beesu modprobe ath9k; fi
Cross posting to Fedora-music also as I think this is of keen interest there (apologies)
Brendan
Hi Brendan
Just a few questions. 1. There's no reason why these scripts cannot run with 0.9.2 right?
The pulseaudio version available in the fc15 repos is at best troublesome and 13 months old... For me at least, there are only 2 options that can be considered:
1) If pulseaudio isn't needed - remove all pulseaudio packages except the the basic library (the pulseaudio library is used by some apps for audio manipulation even if the pulseaudio daemon for input/output is not used/required)
2) Try a more up-to-date pulseaudio version - I had no choice as the younger members of my family insist on Skyping and this only works reliably with pulseaudio and not alsa. Pulseaudio is still not perfect as it won't release the bindings with the audio streams coming from video grabbers which I would like to record directly in sync with the video signal. Pity the Jack-Audio-Connection-Kit is not an Audio-Video-Connection-Kit.
I have researched the internet but have been unable to find a reliable working solution to record combined video/audio sources - any ideas?
- what version of jackd are you using - from the repos? or have you
compiled your own with DBUS support? (jackdbus only just hit f16 recently and you are using f15)
The 1.9.7-2 version in the fedora 15 repos is dbus enabled ;}
As for your question about a2jmidid I just pkill it also.
There must be a better/more professional way of doing this - since a2jmidid is dbus capable.
Another script I use in f16 that I put in my path is this: (the $1 parameter is either start or stop. pre|post in yr examples). I'm a developer so most people won't be using a lot of these services anyway, but you can tailor it for your needs:
fedora16:~ $ cat ~/bin/audio_services #!/bin/bash beesu systemctl $1 nfs-idmap.service nfs-lock.service ksm.service ksmtuned.service abrtd.service cups.socket cups.service sm-client.service sendmail.service ntpd.service mysqld.service httpd.service libvirtd.service crond.service sshd.service smb.service if [ $1 == "stop" ] then beesu modprobe -r ath9k else beesu modprobe ath9k; fi
That's an interesting idea, especially as my laptop is multi-user and I need a solution where the default configuration can be used by everybody but I can "switch" into a special audio configuration as and when required.
It would be nice if Fedora-music could pick this up a make a nice gui which would allow a normal user to switch an installation into an audio/video optimsed mode and back to an home-office mode.
Cross posting to Fedora-music also as I think this is of keen interest there (apologies)
The biggest contribution that the Fedora-music team can make is too persuade the fedora-core team to introduce a rolling update release aka openSUSE Tumbelweed and Linux Mint. The multimedia apps (on linux) are bleeding edge whereby the developers of the most interesting apps are willing to make bug fixes and introduce new features quickly. Unfortunately, these improvements upstream never filter down to the fedora repos mostly because there are too few fedora packagers. A single rolling release with snapshot releases for marketing purposes would meet fedora aims for an actual distribution and significantly reduce the work load.
Happy New Year, Simon
Hi:
On 01/01/2012 05:14 AM, Simon Lewis wrote:
... The biggest contribution that the Fedora-music team can make is too persuade the fedora-core team to introduce a rolling update release aka openSUSE Tumbelweed and Linux Mint. The multimedia apps (on linux) are bleeding edge whereby the developers of the most interesting apps are willing to make bug fixes and introduce new features quickly. Unfortunately, these improvements upstream never filter down to the fedora repos mostly because there are too few fedora packagers. A single rolling release with snapshot releases for marketing purposes would meet fedora aims for an actual distribution and significantly reduce the work load.
I used to be a supporter of the rolling-release idea, but it seems to me that Fedora already strikes a good balance. As you noted, it all comes down to the initiative and number of package maintainers.
Some packages, such as the kernel, are generally updated when new upstream versions are ready. More often than not, it seems, both of the currently-maintained Fedora releases are running or are about to run the same kernel version. Even KDE has generally followed this update pattern, although it was broken with Fedora 15 and 16, which have KDE 4.6 and 4.7, respectively.
All I'm really saying is that convincing everybody to switch to a rolling release is going to be more effort than it's worth, because Fedora already accepts major version updates to packages in the same OS release cycle. As you noted, what we need is more packagers.
Christopher.
Hello Christopher
Many thanks for your response.
Yes, the kernel updates in fc15 are very positive and in terms of device support the 3.1.x (aka 2.6.41.x) is very good.
My main grip is with the fixed releases as there always comes a point when I have no choice but to upgrade to a newer fedora release because I need a particular (new) feature in an application that will not build against the out-dated libraries in the currently installed released, and the libraries cannot be updated because of soname/sonumber bumps, etc..
Just to give an example, I have just received notification from the digikam developers that the mpeg video export has been reintroduced after 2 years absence (whilst digikam was rebuilt against kde4). Unfortunately digikam 2.4 cannot be built against the KDE 4.6.x libraries....
The preupgrade package/route has proved to work well over the years... but there are always a number of apps that I need to build from scratch and configuration options that I need to set after upgrading to get a working system to my requirements. I don't have that much spare time as I would like to concentrate on Linux and usually need 3-4 months after a new fedora release before I can be creative/productive again. Thus from a user point of view a rolling update is very attractive. Doubling up computers to bridge the gap is not a financial option.
Does fedora need more packagers, or should all options to reduce the workload be investigated? Is maintaining several releases or just one rolling release cause more work? I can understand fixed releases for enterprise systems whereby a large number of proprietary applications (e.g. CAD/CMS systems) are installed, but this is not the fedora user base.
Best regards, Simon
Am 01.01.2012 22:57, schrieb Christopher Antila:
Hi:
On 01/01/2012 05:14 AM, Simon Lewis wrote:
... The biggest contribution that the Fedora-music team can make is too persuade the fedora-core team to introduce a rolling update release aka openSUSE Tumbelweed and Linux Mint. The multimedia apps (on linux) are bleeding edge whereby the developers of the most interesting apps are willing to make bug fixes and introduce new features quickly. Unfortunately, these improvements upstream never filter down to the fedora repos mostly because there are too few fedora packagers. A single rolling release with snapshot releases for marketing purposes would meet fedora aims for an actual distribution and significantly reduce the work load.
I used to be a supporter of the rolling-release idea, but it seems to me that Fedora already strikes a good balance. As you noted, it all comes down to the initiative and number of package maintainers.
Some packages, such as the kernel, are generally updated when new upstream versions are ready. More often than not, it seems, both of the currently-maintained Fedora releases are running or are about to run the same kernel version. Even KDE has generally followed this update pattern, although it was broken with Fedora 15 and 16, which have KDE 4.6 and 4.7, respectively.
All I'm really saying is that convincing everybody to switch to a rolling release is going to be more effort than it's worth, because Fedora already accepts major version updates to packages in the same OS release cycle. As you noted, what we need is more packagers.
Christopher. _______________________________________________ music mailing list music@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/music
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Simon :
I've obviously never encountered anything like your use case. How is it that it takes you 3-4 months to become productive in a newly-installed Fedora release? It only takes me about 3-4 hours--clearly you're doing something time-consuming. My intuition suggests you're probably compiling applications that aren't in the Fedora or Planet CCRMA repositories... but a rolling release would make this worse, because your applications would break at unexpected times.
So to continue the solution-finding discussion, I have two questions: 1.) Why does it take you 3-4 months to be productive in a Fedora release, and how could that be reduced to 5 minutes? Let's hear your ideal situation, no matter how impractical it is (might be!) 2.) You suggested that "more packagers" isn't the only way to an audio-production Fedora spin. What other strategies did you have in mind? OpenSuse Build Service?
Christopher.
On 01/02/2012 05:01 AM, Simon Lewis wrote:
Hello Christopher
Many thanks for your response.
Yes, the kernel updates in fc15 are very positive and in terms of device support the 3.1.x (aka 2.6.41.x) is very good.
My main grip is with the fixed releases as there always comes a point when I have no choice but to upgrade to a newer fedora release because I need a particular (new) feature in an application that will not build against the out-dated libraries in the currently installed released, and the libraries cannot be updated because of soname/sonumber bumps, etc..
Just to give an example, I have just received notification from the digikam developers that the mpeg video export has been reintroduced after 2 years absence (whilst digikam was rebuilt against kde4). Unfortunately digikam 2.4 cannot be built against the KDE 4.6.x libraries....
The preupgrade package/route has proved to work well over the years... but there are always a number of apps that I need to build from scratch and configuration options that I need to set after upgrading to get a working system to my requirements. I don't have that much spare time as I would like to concentrate on Linux and usually need 3-4 months after a new fedora release before I can be creative/productive again. Thus from a user point of view a rolling update is very attractive. Doubling up computers to bridge the gap is not a financial option.
Does fedora need more packagers, or should all options to reduce the workload be investigated? Is maintaining several releases or just one rolling release cause more work? I can understand fixed releases for enterprise systems whereby a large number of proprietary applications (e.g. CAD/CMS systems) are installed, but this is not the fedora user base.
Best regards, Simon
Am 01.01.2012 22:57, schrieb Christopher Antila:
Hi:
On 01/01/2012 05:14 AM, Simon Lewis wrote:
... The biggest contribution that the Fedora-music team can make is too persuade the fedora-core team to introduce a rolling update release aka openSUSE Tumbelweed and Linux Mint. The multimedia apps (on linux) are bleeding edge whereby the developers of the most interesting apps are willing to make bug fixes and introduce new features quickly. Unfortunately, these improvements upstream never filter down to the fedora repos mostly because there are too few fedora packagers. A single rolling release with snapshot releases for marketing purposes would meet fedora aims for an actual distribution and significantly reduce the work load.
I used to be a supporter of the rolling-release idea, but it seems to me that Fedora already strikes a good balance. As you noted, it all comes down to the initiative and number of package maintainers.
Some packages, such as the kernel, are generally updated when new upstream versions are ready. More often than not, it seems, both of the currently-maintained Fedora releases are running or are about to run the same kernel version. Even KDE has generally followed this update pattern, although it was broken with Fedora 15 and 16, which have KDE 4.6 and 4.7, respectively.
All I'm really saying is that convincing everybody to switch to a rolling release is going to be more effort than it's worth, because Fedora already accepts major version updates to packages in the same OS release cycle. As you noted, what we need is more packagers.
Christopher. _______________________________________________ music mailing list music@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/music
_______________________________________________ music mailing list music@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/music
On 01/01/2012 11:14 AM, Simon Lewis wrote:
As for your question about a2jmidid I just pkill it also.
There must be a better/more professional way of doing this - since a2jmidid is dbus capable.
Your right, although I have not tried it. /usr/bin/a2j_control should be used to start/stop in D-Bus mode. More details here. /usr/share/doc/a2jmidid-7/README
Another script I use in f16 that I put in my path is this: (the $1 parameter is either start or stop. pre|post in yr examples). I'm a developer so most people won't be using a lot of these services anyway, but you can tailor it for your needs:
fedora16:~ $ cat ~/bin/audio_services #!/bin/bash beesu systemctl $1 nfs-idmap.service nfs-lock.service ksm.service ksmtuned.service abrtd.service cups.socket cups.service sm-client.service sendmail.service ntpd.service mysqld.service httpd.service libvirtd.service crond.service sshd.service smb.service if [ $1 == "stop" ] then beesu modprobe -r ath9k else beesu modprobe ath9k; fi
That's an interesting idea, especially as my laptop is multi-user and I need a solution where the default configuration can be used by everybody but I can "switch" into a special audio configuration as and when required.
It would be nice if Fedora-music could pick this up a make a nice gui which would allow a normal user to switch an installation into an audio/video optimsed mode and back to an home-office mode.
I'm always thinking of the better ways to tackle this. Perhaps we could do something as you suggest... shouldn't be too hard.
Cross posting to Fedora-music also as I think this is of keen interest there (apologies)
The biggest contribution that the Fedora-music team can make is too persuade the fedora-core team to introduce a rolling update release aka openSUSE Tumbelweed and Linux Mint. The multimedia apps (on linux) are bleeding edge whereby the developers of the most interesting apps are willing to make bug fixes and introduce new features quickly. Unfortunately, these improvements upstream never filter down to the fedora repos mostly because there are too few fedora packagers. A single rolling release with snapshot releases for marketing purposes would meet fedora aims for an actual distribution and significantly reduce the work load.
Have you tried Rawhide? I maintain rawhide on at least two of my systems, with only the very occasional breakages. Fedora as a distribution tends to be the first to go with the big changes (I'm thinking systemd / Gnome 3 etc) and I'm not sure that this kind of effort could be coordinated into smaller rolling releases. I find that most packages are relatively up to date in rawhide / rawhide -1 . Raising bugs to alert packages to new upstream releases is always a really good idea. Some packagers maintain so many it is hard to keep track of.
Happy New Year, Simon
Happy New Year to all
Brendan
music mailing list music@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/music