[PlanetCCRMA] FC8, experience so far + pulse audio ...

Nicholas Manojlovic nicholasmanojlovic at gmail.com
Wed May 7 02:28:00 PDT 2008


A point;

Stanford is the world renowned and recognised resource on computer music, so
why is Fedora doing the packaging?

I really liked the first paragraph of the first post, summed things up
perfectly.

On Wed, May 7, 2008 at 12:51 AM, Fernando Lopez-Lezcano <
nando at ccrma.stanford.edu> wrote:

> On Tue, 2008-05-06 at 09:19 -0400, Mike Mazarick wrote:
> > I had issues with getting sound to come out from either the newly
> > minted linux drivers or from the Via onboard chipset (although the Via
> > soundcard seemed to work better, it had more latency).   One of the
> > big issues was trying to figure out from the Jack messages, the
> > dmesgs, or the scsconfig.log or scsrun.log what the issues were.
>
> The Jack error and warning messages are not the most friendly ones in
> the universe... You should see the ones that the experimental jackmp
> prints..., they are even more cryptic :-)
>
> > So far, I've de-installed anything related to pulse-audio (because of
> > Jack messages, and because it seems to default to 2 audio channels
> > running 44.1khz).   I'm also very wary of 'new' stuff, and noticed
> > that this is supposed to be a replacement for Jack.
>
> Pulse Audio? No, Pulse Audio is not meant to replace Jack.
>
> It has a very different goal, which is to provide a unified way in which
> desktop applications can share the audio i/o. It has been tried many
> times before, but it looks like this time this solution is gathering
> momentum. I'm sure some other big project will come up with a newer
> brighter idea, and an incompatible one so that we are back to square
> one :-P
>
> I _think_ Pulse Audio has/will have a way to connect to Jack, ie: be a
> jack client by itself. But I'm not sure.
>
> On the other hand, Jack was never intended to be an "audio daemon" for
> the desktop. It does not have the right stuff for that. So Pulse Audio
> or something similar is still needed.
>
> Pulse Audio can be managed through a control panel and it can be made to
> release the audio resources so that other programs (for example Jack)
> can use them.
>
> > I'd just as soon wait until it is known and proven to be better than
> > Jack (I just switched from CVS to SVN last month).   I also disabled
> > the firewall, because I didn't want to spend many hours googling
> > issues only to discover it is 'security' related (I need to get X out
> > of the system and on to a PC, for instance).   Fedora is really a beta
> > release for RedHat, so, you are always on the 'bleeding edge' for a
> > few months until the fixes come out.
>
> It is an it is not (a beta for redhat). It was more so at the beginning
> of the Fedora project. Still, it is by no means a "conservative"
> distribution :-) It is in the bleeding edge and that has good and bad
> vibes associated with it.
>
> There are many decisions Fedora took that I hate and that affected audio
> apps. Sigh. Maybe it is time to start learning debian packaging :-)
>
> > I can understand permissions and ownership, but I don't necessarily
> > understand how you can get something owned by user-root, group-root
> > with no world r/w to work unless there is some ACL structure (which I
> > don't want to understand or have to know the details of).
>
> Well, I don't understand it either. As it worked for me I assumed
> nothing had changed. So much for me being up to date.
>
> ... curious ...
>
> Hmmm, looks like the switch to ConsoleKit is related (at least partly)
> to fast user switching (ie: having more than one user logged in and
> swithing between them "fast" - never tried myself). See:
>
> http://fedoraproject.org/wiki/Desktop/FastUserSwitching
>
> Apparently simple device node permissions access would not be enough in
> those situations (from what little I understand).
>
> I still don't fully understand the mechanism used (it is ACL's, of
> course) but well, it seems to be working - apparently not always,
> though :-<
>
> Here's a long thread about it:
> https://bugzilla.redhat.com/show_bug.cgi?id=228110
> If I had time I'd read it...
>
> Do a:
>
>    getfacl /dev/snd/*
>
> (part of the acl package) to see who _really_ has access to the sound
> devices...
>
> > I do believe based on experience that some reasonable percentage of
> > the folks trying out sound (and especially Jack) on a FC8 linux daw
> > are running into problems and giving up.
>
> That's too bad but understandable. Anyway, let me know of problems and
> if they are within my power to fix I'll try...
>
> [MUNCH]
> > The Planet has really done a good job of helping people out over the
> > years.    There is usually some type of workaround.   The issue we're
> > currently facing is to explain to a Windows DAW user ( the average
> > user of a GL cards) the compelling reasons to switch to Linux.   Have
> > PlanetCCRMA available is one of the reasons.
>
> Well, there are many options available now, perhaps Planet CCRMA is no
> longer (if it ever was) the best for beginners.
>
> > PS – one small off topic side note – Dave Marion had found that the
> > Gadget Labs cards can be clocked together even if they are in
> > different systems.
>
> Hmmm, that should be true of any card that has an external clock input.
>
> > This opens up the question of multiple Jacks on multiple systems.   It
> > may be that multiple GL cards on multiple systems with sync'd clocks
> > may be the least expensive Wave Front Synthesis system when coupled
> > with several inexpensive 5.1  sound PC speakers.
>
> Interesting thought... netjack perhaps? (it is included in newer svn
> versions of jack). There is still the issue of frame level synch of
> processes on different machines so that all audio is output at the
> exact same time in all of them, right?
>
> -- Fernando
>
>
> _______________________________________________
> PlanetCCRMA mailing list
> PlanetCCRMA at ccrma.stanford.edu
> http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ccrma-mail.stanford.edu/pipermail/planetccrma/attachments/20080507/151c3535/attachment-0001.html 


More information about the PlanetCCRMA mailing list