Re: [Fedora-music-list] [PlanetCCRMA] pulseaudio-1.1-3

[Brendan Jones]

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(a)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

[PlanetCCRMA] pulseaudio-1.1-3

[Simon Lewis]

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?

>  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) 
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

[PlanetCCRMA] pulseaudio-1.1-3

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

[PlanetCCRMA] pulseaudio-1.1-3

[Brendan Jones]

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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/music

[PlanetCCRMA] pulseaudio-1.1-3

[Simon Lewis]

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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/music

[PlanetCCRMA] pulseaudio-1.1-3

[Christopher Antila]

-----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(a)lists.fedoraproject.org 
> > https://admin.fedoraproject.org/mailman/listinfo/music
>  
>  _______________________________________________ music mailing list 
>  music(a)lists.fedoraproject.org 
> >  https://admin.fedoraproject.org/mailman/listinfo/music
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.18 (GNU/Linux)
>
> iQEcBAEBAgAGBQJPB4JvAAoJEInCktGVqZ8Vh9gH/0ieYprxnvQDHoa4Cd/I0r8N
> BE/brMO+J6dj40wOamJToXK9GPoveZdkSfutDS/+MEiHViL+/lojEMzNEkwVUPoC
> yOOMKuDMwf+O+62hCcR1RrMB8V5B5MTIFP31x3we1yd1HyVLmXz5kacbUGO2HeS6
> t75tReWeRiCPAO90MqF/82XGEEVgBRA/flvLGv7RkRJp1FUgV66SrKGmGDIqQL7q
> T+oYOqObX9l6sX6k5Y04eWO+xDZllIsR61EvE+W7jstVBWydocphLePC2uo4h7ej
> PMMRe+PY4cu38LzKL6MgY8jDtxIjEw1u0nI2iv7tR07+qQuwxSc5shECKZwhKrk=
> =335r
> -----END PGP SIGNATURE-----