MusE - Linux Music Editor

thanks for the heads up on this James.. much appreciated.

best,

g. 


Geoff Beasley
Composer,Arranger,Performer,Producer.
Laughing Boy Records
2 Stott Street, Preston, Victoria, Australia  3072
 http://www.laughingboyrecords.com

Hi All 

Sorry for top posting.. but there is so much info below I thought I'd
put my question.. 

I followed all the information below .. and /dev/rtc0 is owned by
root:audio  but muse still gives the output 

RtcTimer::setTimerFreq(): cannot set tick on /dev/rtc: Permission denied
  precise timer not available
Trying ALSA timer...
AlsaTimer::initTimer(): best available ALSA timer: system timer
got timer = 56
starting with default template


Any tips here.. Is this kernel compilation related or am I missing
something?

BTW I'm on Gentoo.. 

Regards

Allan 

On Tue, 2009-12-15 at 15:16 +0000, james morris wrote:
> I've been struggling with setting up the real-time-clock. It's taken me
> a long time to find the right information. And I'm still having
> problems with udev though.
> 
> Here's a messy jumbled collection of stuff I've found out:
> 
> 
> Firstly, setting the frequency of the real-time-clock:
> 
> from linux-2.6.31.6/Documentation/rtc.txt:
> 
> Linux has two largely-compatible userspace RTC API families you may
> need to know about:
> 
>     *   /dev/rtc ... is the RTC provided by PC compatible systems,
>         so it's not very portable to non-x86 systems.
> 
>     *   /dev/rtc0, /dev/rtc1 ... are part of a framework that's
>         supported by a wide variety of RTC chips on all systems.
> 
> ...
>         Old PC/AT-Compatible driver:  /dev/rtc
> ...
> Programming and/or enabling interrupt frequencies greater than 64Hz is
> only allowed by root. This is perhaps a bit conservative, but we don't
> want
> an evil user generating lots of IRQs on a slow 386sx-16, where it might
> have
> a negative impact on performance. This 64Hz limit can be changed by
> writing
> a different value to /proc/sys/dev/rtc/max-user-freq. Note that the
> ...
>         New portable "RTC Class" drivers:  /dev/rtcN
>         --------------------------------------------
> (( ie what I have, and probably others do too if they're running a new
> kernel ))
> 
> Because Linux supports many non-ACPI and non-PC platforms, some of which
> have more than one RTC style clock, it needed a more portable solution
> than expecting a single battery-backed MC146818 clone on every system.
> Accordingly, a new "RTC Class" framework has been defined.  It offers
> three different userspace interfaces:
> 
>     *   /dev/rtcN ... much the same as the older /dev/rtc interface
> 
> *****-> /sys/class/rtc/rtcN ... sysfs attributes support readonly
> *****-> access to some RTC attributes
> 
>     *   /proc/driver/rtc ... the first RTC (rtc0) may expose itself
>         using a procfs interface.  More information is (currently) shown
>         here than through sysfs.
> 
> ------------------------
> 
> sysctl dev.rtc.max-user-freq no longer exists in the kernel
> https://bugzilla.redhat.com/show_bug.cgi?id=431163
> 
> basically telling us what I missed first time round in the kernel rtc
> docs, namely: max-user-freq is now located here:
> 
> /sys/class/rtc/rtc0/max-user-freq
> 
> and to set (until next reboot):
> 
> sudo echo 2048 > /sys/class/rtc/rtc0/max-user-freq
> 
> 
> Finally, How to set the RTC max_user_freq in newer kernels (permanently):
> http://www.ralree.com/2009/07/19/how-to-set-the-rtc-max_user_freq-in-newer-kernels/
> 
> "I found out today how to set the real time clock max frequencies in
> Ubuntu since they removed the possibility to do it from sysutil.conf
> from newer kernels. Add the following to your /etc/rc.local or another
> startup script:"
> 
> sudo echo 2048 >/sys/class/rtc/rtc0/max_user_freq
> sudo echo 2048 >/proc/sys/dev/hpet/max-user-freq
> 
> I only needed the first of these - /proc/sys/dev/hpet does not exist on
> my system.
> 
> ***********************************************
> 
> Secondly doing all that is not bloody good if when you do ll /dev/rtc*
> you discover /dev/rtc0 is not a member of the audio group:
> 
> lrwxrwxrwx 1 root root       4 2009-12-15 14:49 /dev/rtc -> rtc0
> crw-rw---- 1 root root  254, 0 2009-12-15 14:49 /dev/rtc0
> 
> Chances are you're running udev, so don't think you can simply:
> sudo chgrp audio /dev/rtc0
> 
> This is where I've not quite discovered a solution which does not get
> blasted away by a Debian (testing) udev update (so if you know how to do
> it let us know):
> 
> do:
> sudo nano /lib/udev/rules.d/85-hwclock.rules
> 
> and add the following line:
> KERNEL=="rtc0", GROUP:="audio"
> 
> Again it took quite a lot of digging around to find that. Most
> information points to other locations. For example adding the above line
> to /etc/udev/udev.conf does not work. I had previously added a file
> containing the above line to /etc/udev/rules.d but as stuff in there is
> auto-generated... I'm 75% sure it was deleted on a udev update.
> 
> Now I no longer get
> /dev/rtc: permission denied
> 
> Hooray!
> 
> James.
> 
> ------------------------------------------------------------------------------
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
> _______________________________________________
> Lmuse-user mailing list
> Lmuse-user@...
> https://lists.sourceforge.net/lists/listinfo/lmuse-user

On June 26, 2011 02:04:58 am Allan Klinbail wrote:
> Hi All
>
> Sorry for top posting.. but there is so much info below I thought I'd
> put my question..
>
> I followed all the information below .. and /dev/rtc0 is owned by
> root:audio  but muse still gives the output
>
> RtcTimer::setTimerFreq(): cannot set tick on /dev/rtc: Permission denied
>   precise timer not available
> Trying ALSA timer...
> AlsaTimer::initTimer(): best available ALSA timer: system timer
> got timer = 56
> starting with default template
>
>
> Any tips here.. Is this kernel compilation related or am I missing
> something?
Are you using Jack Midi?
The last time I looked into this a long time ago I found that Jack Midi 
 took the RTC. And only one thing could use the RTC at a time.
IIRC the solution was to tell Jack not to use midi (no midi driver).
Not very satisfying, but may help in your situation. Try it.

But it was a long time ago... I see a lot has changed, so I could be
 totally wrong by now. 

Tim.

>
> BTW I'm on Gentoo..
>
> Regards
>
> Allan
>
> On Tue, 2009-12-15 at 15:16 +0000, james morris wrote:
> > I've been struggling with setting up the real-time-clock. It's taken me
> > a long time to find the right information. And I'm still having
> > problems with udev though.
> >
> > Here's a messy jumbled collection of stuff I've found out:
> >
> >
> > Firstly, setting the frequency of the real-time-clock:
> >
> > from linux-2.6.31.6/Documentation/rtc.txt:
> >
> > Linux has two largely-compatible userspace RTC API families you may
> > need to know about:
> >
> >     *   /dev/rtc ... is the RTC provided by PC compatible systems,
> >         so it's not very portable to non-x86 systems.
> >
> >     *   /dev/rtc0, /dev/rtc1 ... are part of a framework that's
> >         supported by a wide variety of RTC chips on all systems.
> >
> > ...
> >         Old PC/AT-Compatible driver:  /dev/rtc
> > ...
> > Programming and/or enabling interrupt frequencies greater than 64Hz is
> > only allowed by root. This is perhaps a bit conservative, but we don't
> > want
> > an evil user generating lots of IRQs on a slow 386sx-16, where it might
> > have
> > a negative impact on performance. This 64Hz limit can be changed by
> > writing
> > a different value to /proc/sys/dev/rtc/max-user-freq. Note that the
> > ...
> >         New portable "RTC Class" drivers:  /dev/rtcN
> >         --------------------------------------------
> > (( ie what I have, and probably others do too if they're running a new
> > kernel ))
> >
> > Because Linux supports many non-ACPI and non-PC platforms, some of which
> > have more than one RTC style clock, it needed a more portable solution
> > than expecting a single battery-backed MC146818 clone on every system.
> > Accordingly, a new "RTC Class" framework has been defined.  It offers
> > three different userspace interfaces:
> >
> >     *   /dev/rtcN ... much the same as the older /dev/rtc interface
> >
> > *****-> /sys/class/rtc/rtcN ... sysfs attributes support readonly
> > *****-> access to some RTC attributes
> >
> >     *   /proc/driver/rtc ... the first RTC (rtc0) may expose itself
> >         using a procfs interface.  More information is (currently) shown
> >         here than through sysfs.
> >
> > ------------------------
> >
> > sysctl dev.rtc.max-user-freq no longer exists in the kernel
> > https://bugzilla.redhat.com/show_bug.cgi?id=431163
> >
> > basically telling us what I missed first time round in the kernel rtc
> > docs, namely: max-user-freq is now located here:
> >
> > /sys/class/rtc/rtc0/max-user-freq
> >
> > and to set (until next reboot):
> >
> > sudo echo 2048 > /sys/class/rtc/rtc0/max-user-freq
> >
> >
> > Finally, How to set the RTC max_user_freq in newer kernels (permanently):
> > http://www.ralree.com/2009/07/19/how-to-set-the-rtc-max_user_freq-in-newe
> >r-kernels/
> >
> > "I found out today how to set the real time clock max frequencies in
> > Ubuntu since they removed the possibility to do it from sysutil.conf
> > from newer kernels. Add the following to your /etc/rc.local or another
> > startup script:"
> >
> > sudo echo 2048 >/sys/class/rtc/rtc0/max_user_freq
> > sudo echo 2048 >/proc/sys/dev/hpet/max-user-freq
> >
> > I only needed the first of these - /proc/sys/dev/hpet does not exist on
> > my system.
> >
> > ***********************************************
> >
> > Secondly doing all that is not bloody good if when you do ll /dev/rtc*
> > you discover /dev/rtc0 is not a member of the audio group:
> >
> > lrwxrwxrwx 1 root root       4 2009-12-15 14:49 /dev/rtc -> rtc0
> > crw-rw---- 1 root root  254, 0 2009-12-15 14:49 /dev/rtc0
> >
> > Chances are you're running udev, so don't think you can simply:
> > sudo chgrp audio /dev/rtc0
> >
> > This is where I've not quite discovered a solution which does not get
> > blasted away by a Debian (testing) udev update (so if you know how to do
> > it let us know):
> >
> > do:
> > sudo nano /lib/udev/rules.d/85-hwclock.rules
> >
> > and add the following line:
> > KERNEL=="rtc0", GROUP:="audio"
> >
> > Again it took quite a lot of digging around to find that. Most
> > information points to other locations. For example adding the above line
> > to /etc/udev/udev.conf does not work. I had previously added a file
> > containing the above line to /etc/udev/rules.d but as stuff in there is
> > auto-generated... I'm 75% sure it was deleted on a udev update.
> >
> > Now I no longer get
> > /dev/rtc: permission denied
> >
> > Hooray!
> >
> > James.
> >

2011/6/26 Tim E. Real <termtech@...>:
> ...
> The last time I looked into this a long time ago I found that Jack Midi
>  took the RTC. And only one thing could use the RTC at a time.
> ...
> But it was a long time ago... I see a lot has changed, so I could be
>  totally wrong by now.
>

Accessing the RTC directly doesn't appear reasonable to me,
since it can be opened only once.

Using the ALSA timer interface
   http://www.alsa-project.org/alsa-doc/alsa-lib/group___timer.html
looks more appropriate.

With a system - configured accordingly,
ALSA timer itself should use the HPET,
thus providing high enough resolution.

-- 
E.R.

2011/6/26 Emanuel Rumpf <xbran@...>:
>
> With a system - configured accordingly,
> ALSA timer itself should use the HPET,

I mean HR-TIMER


-- 
E.R.

On Sun, 2011-06-26 at 16:15 +0200, Emanuel Rumpf wrote:
> 2011/6/26 Emanuel Rumpf <xbran@...>:
> >
> > With a system - configured accordingly,
> > ALSA timer itself should use the HPET,
> 
> I mean HR-TIMER
> 
> 
Thanks guys 

@ Tim.. Yes I am using Jack Midi
@ Emanuel, the system says it is using ALSA timer but it only gives a
resolution of 56 or something like that... is that right or do I need to
look deeper into configuring ALSA (it is set  in kernel options to use
HR Timer.. so I'm wondering if there is any further intervention
required) 

cheers

Allan

2011/6/28 Allan Klinbail <sonofzev@...>:
> @ Emanuel, the system says it is using ALSA timer but it only gives a
> resolution of 56 or something like that... is that right or do I need to
> look deeper into configuring ALSA (it is set  in kernel options to use
> HR Timer.. so I'm wondering if there is any further intervention
> required)
>

As far as I believe to be informed, HPET is superior to RTC, can
anyone confirm that ?
Timer resolution depends on...

1.  your kernel has to be configured to support HPET and HRTIMER
    below is a list of related kernel options

2. modules must eventually be loaded
   modprobe -v snd-hrtimer
check with
  lsmod | grep -i timer
and list available timers
 cat /proc/asound/timers
    my output:
    G0: system timer : 1000.000us (10000000 ticks)
    G3: HR timer : 0.001us (1000000000 ticks)

3. the application has to use the ALSA  API  appropriately.
( I'm not informed, how this is done in muse )


kernel options:

grep -i hpet /boot/config-2.6.39.2rt
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_HPET=y
CONFIG_HPET_MMAP=y

grep -i timer /boot/config-2.6.39.2rt
CONFIG_HIGH_RES_TIMERS=y
CONFIG_HPET_TIMER=y
CONFIG_SND_TIMER=m
CONFIG_SND_HRTIMER=m
CONFIG_SND_SEQ_HRTIMER_DEFAULT=y

grep -i config_hz /boot/config-2.6.39.2rt
CONFIG_HZ_1000=y
CONFIG_HZ=1000

grep -i "_tick|hrtick" /boot/config-2.6.39.2rt
CONFIG_TICK_ONESHOT=y
CONFIG_SCHED_HRTICK=y



-- 
E.R.

I'm getting this message on an i5 480M hm57 machine. When I run "muse -D," I get the following read out just before the pop up window appears:

no message buffer overruns
no message buffer overruns
unknown option character 1
cannot connect to jack server
cannot create jack client

I have no idea what the problem is.

I just tried it on my old system, and I have the same problem there.  It use to work there. The only thing I've done to the old system is apply system updates and install a few desktop environments, which include all sorts of stuff, such as Pulse.



--- On Thu, 9/8/11, Rob W <h7th@...> wrote:

> From: Rob W <h7th@...>
> Subject: [Lmuse-user] MusE failed to find a jack audio server
> To: lmuse-user@...
> Date: Thursday, September 8, 2011, 11:21 PM
> I'm getting this message on an i5
> 480M hm57 machine. When I run "muse -D," I get the following
> read out just before the pop up window appears:
> 
> no message buffer overruns
> no message buffer overruns
> unknown option character 1
> cannot connect to jack server
> cannot create jack client
> 
> I have no idea what the problem is.
> 
> ------------------------------------------------------------------------------
> Why Cloud-Based Security and Archiving Make Sense
> Osterman Research conducted this study that outlines how
> and why cloud
> computing security and archiving is rapidly being adopted
> across the IT 
> space for its ease of implementation, lower cost, and
> increased 
> reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
> _______________________________________________
> Lmuse-user mailing list
> Lmuse-user@...
> https://lists.sourceforge.net/lists/listinfo/lmuse-user
>

if you need jack, start jack. qjackctl is a nice frontend for it
if you don't, start muse with one or more of -apIL. dunno if this 
doesn't disable too much for you, however

greetings
flo

Am 09.09.2011 05:46, schrieb Rob W:
> I just tried it on my old system, and I have the same problem there.  It use to work there. The only thing I've done to the old system is apply system updates and install a few desktop environments, which include all sorts of stuff, such as Pulse.
>
>
>
> --- On Thu, 9/8/11, Rob W<h7th@...>  wrote:
>
>    
>> From: Rob W<h7th@...>
>> Subject: [Lmuse-user] MusE failed to find a jack audio server
>> To: lmuse-user@...
>> Date: Thursday, September 8, 2011, 11:21 PM
>> I'm getting this message on an i5
>> 480M hm57 machine. When I run "muse -D," I get the following
>> read out just before the pop up window appears:
>>
>> no message buffer overruns
>> no message buffer overruns
>> unknown option character 1
>> cannot connect to jack server
>> cannot create jack client
>>
>> I have no idea what the problem is.
>>
>> ------------------------------------------------------------------------------
>> Why Cloud-Based Security and Archiving Make Sense
>> Osterman Research conducted this study that outlines how
>> and why cloud
>> computing security and archiving is rapidly being adopted
>> across the IT
>> space for its ease of implementation, lower cost, and
>> increased
>> reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
>> _______________________________________________
>> Lmuse-user mailing list
>> Lmuse-user@...
>> https://lists.sourceforge.net/lists/listinfo/lmuse-user
>>
>>      
> ------------------------------------------------------------------------------
> Why Cloud-Based Security and Archiving Make Sense
> Osterman Research conducted this study that outlines how and why cloud
> computing security and archiving is rapidly being adopted across the IT
> space for its ease of implementation, lower cost, and increased
> reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
> _______________________________________________
> Lmuse-user mailing list
> Lmuse-user@...
> https://lists.sourceforge.net/lists/listinfo/lmuse-user
>
>

It only runs when I use the -a option, but I really need audio support.  It does open if I use jackd1, but then I am not able to set audio inputs.


--- On Fri, 9/9/11, Florian Jung <florian.a.jung@...> wrote:

> From: Florian Jung <florian.a.jung@...>
> Subject: Re: [Lmuse-user] MusE failed to find a jack audio server
> To: lmuse-user@...
> Date: Friday, September 9, 2011, 11:02 AM
> if you need jack, start jack.
> qjackctl is a nice frontend for it
> if you don't, start muse with one or more of -apIL. dunno
> if this 
> doesn't disable too much for you, however
> 
> greetings
> flo
> 
> Am 09.09.2011 05:46, schrieb Rob W:
> > I just tried it on my old system, and I have the same
> problem there.  It use to work there. The only thing
> I've done to the old system is apply system updates and
> install a few desktop environments, which include all sorts
> of stuff, such as Pulse.
> >
> >
> >
> > --- On Thu, 9/8/11, Rob W<h7th@...> 
> wrote:
> >
> >    
> >> From: Rob W<h7th@...>
> >> Subject: [Lmuse-user] MusE failed to find a jack
> audio server
> >> To: lmuse-user@...
> >> Date: Thursday, September 8, 2011, 11:21 PM
> >> I'm getting this message on an i5
> >> 480M hm57 machine. When I run "muse -D," I get the
> following
> >> read out just before the pop up window appears:
> >>
> >> no message buffer overruns
> >> no message buffer overruns
> >> unknown option character 1
> >> cannot connect to jack server
> >> cannot create jack client
> >>
> >> I have no idea what the problem is.
> >>
> >>
> ------------------------------------------------------------------------------
> >> Why Cloud-Based Security and Archiving Make Sense
> >> Osterman Research conducted this study that
> outlines how
> >> and why cloud
> >> computing security and archiving is rapidly being
> adopted
> >> across the IT
> >> space for its ease of implementation, lower cost,
> and
> >> increased
> >> reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
> >> _______________________________________________
> >> Lmuse-user mailing list
> >> Lmuse-user@...
> >> https://lists.sourceforge.net/lists/listinfo/lmuse-user
> >>
> >>      
> >
> ------------------------------------------------------------------------------
> > Why Cloud-Based Security and Archiving Make Sense
> > Osterman Research conducted this study that outlines
> how and why cloud
> > computing security and archiving is rapidly being
> adopted across the IT
> > space for its ease of implementation, lower cost, and
> increased
> > reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
> > _______________________________________________
> > Lmuse-user mailing list
> > Lmuse-user@...
> > https://lists.sourceforge.net/lists/listinfo/lmuse-user
> >
> >    
> 
> 
> ------------------------------------------------------------------------------
> Why Cloud-Based Security and Archiving Make Sense
> Osterman Research conducted this study that outlines how
> and why cloud
> computing security and archiving is rapidly being adopted
> across the IT 
> space for its ease of implementation, lower cost, and
> increased 
> reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
> _______________________________________________
> Lmuse-user mailing list
> Lmuse-user@...
> https://lists.sourceforge.net/lists/listinfo/lmuse-user
>

Hi Rob,

2011/9/10 Rob W <h7th@...>:
> It only runs when I use the -a option, but I really need audio support.  It does open if I use jackd1, but then I am not able to set audio inputs.

Ok, what do you mean by not being able to set audio inputs?
MusE should work just fine in this configuration...
You add an input track in muse and connect it to a jack input port.

About the jack2 issue, having several versions of jack installed may
be a problem. I forget exactly how the versioning for jack works but
you may need to recompile muse with dev packages for jack2.
Maybe someone else has more knowledge about this.
Wierd that you ended up in this situation on the old system only by
updating packages..
Btw, is your muse self compiled?

Regards,
Robert

Muse is not self compiled.  

When I add an input track, I can not make a jack connection.  I can not see any options when I click on the mixer button at the bottom of the channel strip.



--- On Sat, 9/10/11, Robert Jonsson <spamatica@...> wrote:

> From: Robert Jonsson <spamatica@...>
> Subject: Re: [Lmuse-user] MusE failed to find a jack audio server
> To: "Rob W" <h7th@...>
> Cc: "muse >> lmuse-user" <lmuse-user@...>
> Date: Saturday, September 10, 2011, 5:00 AM
> Hi Rob,
> 
> 2011/9/10 Rob W <h7th@...>:
> > It only runs when I use the -a option, but I really
> need audio support.  It does open if I use jackd1, but then
> I am not able to set audio inputs.
> 
> Ok, what do you mean by not being able to set audio
> inputs?
> MusE should work just fine in this configuration...
> You add an input track in muse and connect it to a jack
> input port.
> 
> About the jack2 issue, having several versions of jack
> installed may
> be a problem. I forget exactly how the versioning for jack
> works but
> you may need to recompile muse with dev packages for
> jack2.
> Maybe someone else has more knowledge about this.
> Wierd that you ended up in this situation on the old system
> only by
> updating packages..
> Btw, is your muse self compiled?
> 
> Regards,
> Robert
>

Hi Rob,

2011/9/25 Rob W <h7th@...>:
> Muse is not self compiled.
>
> When I add an input track, I can not make a jack connection.  I can not see any options when I click on the mixer button at the bottom of the channel strip.

I assume you mean the iR button.

When using jack1 it seems it does not see your soundcard, maybe this
is the root cause.
Have you confirmed that you can connect some other application to jack?

With jack there is a utility jack_lsp that lists all available ports,
if you try it in a terminal it should list your soundcard inputs and
outputs. E.g.
$ jack_lsp
system:capture_1
system:capture_2
system:playback_1
system:playback_2

Do try it with both jack1 and jack2.

--
An idea is that it may be pulseaudio that somehow hides your soundcard.

Regards,
Robert

It works now after updating my OS to Xubuntu 11.10.  Yes, jack did work with other apps.



----- Original Message -----
From: Robert Jonsson <spamatica@...>
To: Rob W <h7th@...>; "muse >> lmuse-user" <lmuse-user@...>
Cc: 
Sent: Monday, September 26, 2011 3:03 AM
Subject: Re: [Lmuse-user] MusE failed to find a jack audio server

Hi Rob,

2011/9/25 Rob W <h7th@...>:
> Muse is not self compiled.
>
> When I add an input track, I can not make a jack connection.  I can not see any options when I click on the mixer button at the bottom of the channel strip.

I assume you mean the iR button.

When using jack1 it seems it does not see your soundcard, maybe this
is the root cause.
Have you confirmed that you can connect some other application to jack?

With jack there is a utility jack_lsp that lists all available ports,
if you try it in a terminal it should list your soundcard inputs and
outputs. E.g.
$ jack_lsp
system:capture_1
system:capture_2
system:playback_1
system:playback_2

Do try it with both jack1 and jack2.

--
An idea is that it may be pulseaudio that somehow hides your soundcard.

Regards,
Robert

Hi Rob,

Okay, good that you got it working anyway.

Regards,
Robert


2011/10/27 Rob W <h7th@...>

> It works now after updating my OS to Xubuntu 11.10.  Yes, jack did work
> with other apps.
>
>
>
> ----- Original Message -----
> From: Robert Jonsson <spamatica@...>
> To: Rob W <h7th@...>; "muse >> lmuse-user" <
> lmuse-user@...>
> Cc:
> Sent: Monday, September 26, 2011 3:03 AM
> Subject: Re: [Lmuse-user] MusE failed to find a jack audio server
>
> Hi Rob,
>
> 2011/9/25 Rob W <h7th@...>:
> > Muse is not self compiled.
> >
> > When I add an input track, I can not make a jack connection.  I can not
> see any options when I click on the mixer button at the bottom of the
> channel strip.
>
> I assume you mean the iR button.
>
> When using jack1 it seems it does not see your soundcard, maybe this
> is the root cause.
> Have you confirmed that you can connect some other application to jack?
>
> With jack there is a utility jack_lsp that lists all available ports,
> if you try it in a terminal it should list your soundcard inputs and
> outputs. E.g.
> $ jack_lsp
> system:capture_1
> system:capture_2
> system:playback_1
> system:playback_2
>
> Do try it with both jack1 and jack2.
>
> --
> An idea is that it may be pulseaudio that somehow hides your soundcard.
>
> Regards,
> Robert
>
>
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@... Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> _______________________________________________
> Lmuse-user mailing list
> Lmuse-user@...
> https://lists.sourceforge.net/lists/listinfo/lmuse-user
>