Jean-Charles Quillet | 1 Dec 15:43 2006
Picon

Re: [Jackit-devel] Software equalizer


> - Secondly I try to use the jack output plugin for xmms. It makes xmms
> as well as the jack server crash on my system.
> In both case, it is not very usable for me. Unless someone tell me
> about a successful similar experience, I think I'll definitely go into
> developing an alsa plugin.

xmms-jack works fine for me, i use it all day every day. it doesn't
recover very well anymore if jackd is killed, but other than that, its
pretty much perfect. this is not relevant, however, to your goal of
routing all ALSA apps via JACK.

Ok, I tried again and it works now. Sorry about that. It was probably something I badly configured. This experience was just to test jack usability for me. At first, it seems very complicated, but when it is configured correctly I can figure now how powerfull it is.

So, I managed to make jackEQ working as well. I think it is really cool. It works fine.

My only problem is now that the computer I want to equalize the sound hasn't got any screen, think of a media box. So I'd like to be able to change the equalization when needed over ssh. I could start jackEQ over ssh from the network. But I don't want to have two computers on to be able to listen music from one. I might be a bit confused.

So it would be great if jackEQ had a kind of server mode running without X and you could drive it using different interface.

Jean-Charles


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Jackit-devel mailing list
Jackit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Lee Revell | 1 Dec 16:13 2006

Re: [Jackit-devel] Software equalizer

On Fri, 2006-12-01 at 15:43 +0100, Jean-Charles Quillet wrote:
> My only problem is now that the computer I want to equalize the sound
> hasn't got any screen, think of a media box. So I'd like to be able to
> change the equalization when needed over ssh. I could start jackEQ
> over ssh from the network. But I don't want to have two computers on
> to be able to listen music from one. I might be a bit confused. 
> 
> So it would be great if jackEQ had a kind of server mode running
> without X and you could drive it using different interface. 

Just use X11 tunneling over SSH.

Lee

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Daniel James | 1 Dec 16:46 2006

Re: [Jackit-devel] Software equalizer

Hi Lee, hi Jean-Charles

>> So it would be great if jackEQ had a kind of server mode running
>> without X and you could drive it using different interface. 
> 
> Just use X11 tunneling over SSH.

Or patch jackEQ to accept OSC commands. Patrick already has OSC support 
on his wishlist for jackEQ, so I'm sure he'd appreciate some help with that.

Cheers!

Daniel

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Fernando Lopez-Lezcano | 1 Dec 23:49 2006
Picon

[Jackit-devel] advice on how to track xruns...

Hi... I'm trying to track xruns I'm getting on an x86_64 smp platform
running 2.6.19-rt1 (Ingo's latest and greatest). The kernel I'm trying
out has latency tracing enabled and I have a hacked jackd that will
trigger the client traces - and all that seems to be working fine. 

But it looks like the xruns are not happening because of that part of
the jack graph, if I understand what I see (I see new higher latency
traces being triggered but they don't coincide with the xrun messages
from jack, AFAICT). 

Where else could I insert the <begin tracing> and <end tracing>
statements so that other parts of the jackd execution path are covered?
Or do the existing ones cover everything that would need to be covered?

[BTW: the API for the start/end trace in the realtime kernel has
changed, I'm including a tiny patch that fixes that against current cvs]

-- Fernando

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Jackit-devel mailing list
Jackit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Jean-Charles Quillet | 2 Dec 00:08 2006
Picon

Re: [Jackit-devel] Software equalizer

On 12/1/06, Daniel James <daniel <at> 64studio.com> wrote:
>> So it would be great if jackEQ had a kind of server mode running
>> without X and you could drive it using different interface.
>
> Just use X11 tunneling over SSH.

I know, I don't want to involve a X server in this. I just want to tweak the sound of a computer, this should not require a second computer always on.

Or patch jackEQ to accept OSC commands. Patrick already has OSC support
on his wishlist for jackEQ, so I'm sure he'd appreciate some help with that.

Sounds like an interesting idea. I'll definitely have look into OSC.
Thanks.

Jean-Charles

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Jackit-devel mailing list
Jackit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Florian Schmidt | 2 Dec 00:50 2006
X-Face
Picon
Picon

Re: [Jackit-devel] advice on how to track xruns...

On Friday 01 December 2006 23:49, Fernando Lopez-Lezcano wrote:
> Hi... I'm trying to track xruns I'm getting on an x86_64 smp platform
> running 2.6.19-rt1 (Ingo's latest and greatest). The kernel I'm trying
> out has latency tracing enabled and I have a hacked jackd that will
> trigger the client traces - and all that seems to be working fine.
>
> But it looks like the xruns are not happening because of that part of
> the jack graph, if I understand what I see (I see new higher latency
> traces being triggered but they don't coincide with the xrun messages
>
> from jack, AFAICT).
>
> Where else could I insert the <begin tracing> and <end tracing>
> statements so that other parts of the jackd execution path are covered?
> Or do the existing ones cover everything that would need to be covered?
>
> [BTW: the API for the start/end trace in the realtime kernel has
> changed, I'm including a tiny patch that fixes that against current cvs]
>
> -- Fernando

Hi,

the preemption check in jackd bacically only covers the client side. It is run 
in the process of the client and basically checks for voluntary giveup of the 
cpu by the client process [i.e. doing a sleep() or a lock() on a previously 
locked mutex, or any other system call that might give up the cpu].

Some soundcards could produce xruns by having buggy drivers [or buggy hw]. 
I.e. my cs46xx [which went up in smoke some days ago] produced an xrun 
reliably somewhere around every 5-10 minutes on an otherwise perfectly 
tuned -rt system [the ice1712 never showed such a problem - it just runs and 
runs and runs].

My cs46xx chip in my thinkpad t21 shows the same behaviour..

Anyways, if the driver is at fault, then i suppose there are scenarios where 
it can produce an xrun without triggering a preemption check. And jackd could 
in theory at least also be at fault without triggering a preemption check.

Regards,
Flo

--

-- 
Palimm Palimm!
http://tapas.affenbande.org

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Jack O'Quin | 2 Dec 01:10 2006
Picon

[Jackit-devel] default jackd realtime priority

I notice that most users of Ingo's realtime kernel patchset seem to
run jackd at priority 70.  The current default is 10.

It occurs to me that on most non-RT systems any realtime priority
for JACK will perform the same.  As long as there are no other
processes are running with SCHED_FIFO, it makes no difference.

For RT-patched systems, it matters quite a bit, because various
device interrupt handlers are dispatched with settable priorities.
The default is 50, I  believe.

So, my question for those who know about such things is: should
we change the default jackd priority to something like 70?  Or, is
this better left as it is?
--

-- 
 joq

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Fernando Lopez-Lezcano | 2 Dec 01:15 2006
Picon

Re: [Jackit-devel] default jackd realtime priority

On Fri, 2006-12-01 at 18:10 -0600, Jack O'Quin wrote:
> I notice that most users of Ingo's realtime kernel patchset seem to
> run jackd at priority 70.  The current default is 10.
> 
> It occurs to me that on most non-RT systems any realtime priority
> for JACK will perform the same.  As long as there are no other
> processes are running with SCHED_FIFO, it makes no difference.
> 
> For RT-patched systems, it matters quite a bit, because various
> device interrupt handlers are dispatched with settable priorities.
> The default is 50, I  believe.
> 
> So, my question for those who know about such things is: should
> we change the default jackd priority to something like 70?  Or, is
> this better left as it is?

I'm currently patching it to 62 in my packages to match rtirq's
reordering of the irqs in -rt kernels (it is set to be lower than the
soundcard priority level but higher than the other irqs). 

The only problem that I can see is that the right setting will depend on
how rtirq (or any other alternative script) orders the interrupts. 

-- Fernando

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Fernando Lopez-Lezcano | 2 Dec 01:15 2006
Picon

Re: [Jackit-devel] advice on how to track xruns...

On Sat, 2006-12-02 at 00:50 +0100, Florian Schmidt wrote:
> On Friday 01 December 2006 23:49, Fernando Lopez-Lezcano wrote:
> > Hi... I'm trying to track xruns I'm getting on an x86_64 smp platform
> > running 2.6.19-rt1 (Ingo's latest and greatest). The kernel I'm trying
> > out has latency tracing enabled and I have a hacked jackd that will
> > trigger the client traces - and all that seems to be working fine.
> >
> > But it looks like the xruns are not happening because of that part of
> > the jack graph, if I understand what I see (I see new higher latency
> > traces being triggered but they don't coincide with the xrun messages
> >
> > from jack, AFAICT).
> >
> > Where else could I insert the <begin tracing> and <end tracing>
> > statements so that other parts of the jackd execution path are covered?
> > Or do the existing ones cover everything that would need to be covered?
> >
> > [BTW: the API for the start/end trace in the realtime kernel has
> > changed, I'm including a tiny patch that fixes that against current cvs]
>
> the preemption check in jackd bacically only covers the client side. It is run 
> in the process of the client and basically checks for voluntary giveup of the 
> cpu by the client process [i.e. doing a sleep() or a lock() on a previously 
> locked mutex, or any other system call that might give up the cpu].
> 
> Some soundcards could produce xruns by having buggy drivers [or buggy hw]. 
> I.e. my cs46xx [which went up in smoke some days ago] produced an xrun 
> reliably somewhere around every 5-10 minutes on an otherwise perfectly 
> tuned -rt system [the ice1712 never showed such a problem - it just runs and 
> runs and runs].

This is on an ice1712 which otherwise runs fine (same hardware as other
machines that are working fine with earlier releases)

> Anyways, if the driver is at fault, then i suppose there are scenarios where 
> it can produce an xrun without triggering a preemption check. And jackd could 
> in theory at least also be at fault without triggering a preemption check.

That was the reason for my question, how to check latencies from within
jackd that are not originated in the clients themselves... 

-- Fernando

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Taybin Rutkin | 2 Dec 01:42 2006
Picon
Picon

Re: [Jackit-devel] Subject: libjack versioning proposal

On Nov 30, 2006, at 10:57 AM, Jack O'Quin wrote:
>
> I have not yet thought of any show-stopper preventing
> us from being able to handle multiple libjack versions
> on the same system correctly.  So, let's support normal
> Linux library versioning, instead of fighting it.
>
> Probably, I am overlooking some of the difficulties.
> Please let me know what other problems you know about.

I can't think of anything off hand myself.

Taybin

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Gmane