headers
Paul Davis | 1 Apr 2003 04:22

latest CVS commit


   * fix from simon jenkins for incorrect RT-threadness
   * 0.66.3/0.17.0

sorry 'bout that folks. i rarely use -R at the moment, so i didn't
notice the problem.

-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
Permalink | Reply | 2 comments |
headers
Simon Jenkins | 1 Apr 2003 11:35
Picon
Favicon

Re: latest CVS commit

Paul Davis wrote:

>   * fix from simon jenkins for incorrect RT-threadness
>   * 0.66.3/0.17.0
>
Its a bit of a coarse-grained fix cos I posted it before the exact
cause of the problem was understood (by me, anyway).

Simon Jenkins
(Bristol, UK)

-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
Permalink | Reply | 1 comment |
headers
Paul Davis | 1 Apr 2003 15:06

Re: latest CVS commit

>>   * fix from simon jenkins for incorrect RT-threadness
>>   * 0.66.3/0.17.0
>>
>Its a bit of a coarse-grained fix cos I posted it before the exact
>cause of the problem was understood (by me, anyway).

do you want to redo it?

-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
Permalink | Reply | 0 comments |
headers
Simon Jenkins | 1 Apr 2003 20:58
Picon
Favicon

Re: latest CVS commit

Paul Davis wrote:

>>>  * fix from simon jenkins for incorrect RT-threadness
>>>  * 0.66.3/0.17.0
>>>
>>>      
>>>
>>Its a bit of a coarse-grained fix cos I posted it before the exact
>>cause of the problem was understood (by me, anyway).
>>    
>>
>
>do you want to redo it?
>
>  
>
Better to apply Stephane's patch which also fixes some other stuff.

I hadn't intended my diff to be applied as-is, necessarily, (hence no 
PATCH in
subject line), I was just thinking of it as useful information for 
someone hunting
the bug, and useful band-aid if the bug wasn't found quickly.

Simon Jenkins
(Bristol, UK)

-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeremy Hall | 2 Apr 2003 01:41

Re: latest CVS commit

In the new year, Kai Vehmanen wrote:
> On Sat, 22 Mar 2003, Martijn Sipkema wrote:
> 
> It's not really significant. With 2ms engine period/buffersize, and 1ms
> interrupt interval, the additional wakeup latency is max 1ms. You'd of
> course have to utilize a three-period driver buffer between the driver and
> the clients (-> 6ms of driver/device buffering).
> 
Please understand I am taking this out of context, as I haven't fully 
digested this thread, but these words by themselves aren't going to cut it 
for me.  It is not acceptable to me to have to endure 6ms latency.  I 
think we should be able to run 64 frames_per_cycle and deal with the 
constraints.  I personally would like to see 96khz at 64 frames_per_cycle 
reliably, and since I use multiple applications at once with jack, my 
understanding is they need to be OOP clients.  My understanding is ardour 
must for other reasons, although we have discussed that before, so for me 
that means that every cycle counts.

My understanding is that the HDSP might help me with some regards, but if 
I need to run a compressor, I MUST process in software, unless somehow the 
hardware can be given an asm program that does the same things the host 
processing would do, i.e. the ladspa plugins etc gets pushed down into the 
hardware somehow.

_J

-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jeremy Hall | 2 Apr 2003 02:28

Re: Newbie problem..

It looks like in 2.5 you need to make it t ype tmpfs, not type shm.

_J

In the new year, Tomas Doran wrote:
> At 18:05 25/03/2003, Jack O'Quin wrote:
> >Paul Davis <paul <at> linuxaudiosystems.com> writes:
> >
> >That's probably not an issue for most JACK users.  I suspect we're all
> >on 2.4 or 2.5 kernels at this point.  But now, kernel >= 2.4 seems to
> >be a dependency, which I suspect was not the case before.
> 
> Thanks for the help everyone ;)
> 
> I knew I was probably missing something totally trivial..
> 
> I'm not anywhere near (in either space, or network terms) the system I'm 
> trying to get jack to run on, therefore I haven't been able to try it out 
> yet, however I assume this will solve my issue.
> 
> On the same note, the SHMFS issue may shoot people in the foot in future, 
> therefore I have combined the mailing list posts about how to solve it into 
> a mini-patch as IMNSHO the dependency should be documented ;)
> 
> Cheers
> Tom
> 
> (patch follows)
> ___BEGIN_PATCH___
> diff -u -r jack.cvs/README jack/README
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Davis | 2 Apr 2003 14:49

Re: latest CVS commit

>digested this thread, but these words by themselves aren't going to cut it 
>for me.  It is not acceptable to me to have to endure 6ms latency.  I 
>think we should be able to run 64 frames_per_cycle and deal with the 
>constraints.  

the discussion, as i recall, concerns the handling of certain hardware
that uses constant time interrupts rather than constant frame count
interrupts. it was not relevant to devices like most current audio
interfaces which use constant frame count interrupts.

>	       I personally would like to see 96khz at 64 frames_per_cycle 
>reliably, and since I use multiple applications at once with jack, my 
>understanding is they need to be OOP clients.  

that's no longer true. JACK supports internal clients as well these days.

						My understanding is ardour 
>must for other reasons, although we have discussed that before, so for me 
>that means that every cycle counts.

true, ardour is and will likely always be an external client.

--p

-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jeremy Hall | 2 Apr 2003 15:05

Re: latest CVS commit

In the new year, Paul Davis wrote:
> >	       I personally would like to see 96khz at 64 frames_per_cycle 
> >reliably, and since I use multiple applications at once with jack, my 
> >understanding is they need to be OOP clients.  
> 
> that's no longer true. JACK supports internal clients as well these days.
> 
> 						My understanding is ardour 
> >must for other reasons, although we have discussed that before, so for me 
> >that means that every cycle counts.
> 
> true, ardour is and will likely always be an external client.
> 
right, but what I was referring to was your possibility that a OOP client 
could be a jack master, but that it would not accept new connections from 
other applications, effectively making it an in-process app.  Because I 
need to communicate to other external applications, this will never work 
for me.  If your requirements could be bent a little to allow the jackd 
started by an application to allow connections, then it would be an easy 
way to get ardour to be an in-process application.

_J

> --p
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb: 
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
> No other company gives more support or power for your dedicated server
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeremy Hall | 2 Apr 2003 20:35

can no longer have a / in client name

Hi,

Because of the shm changes (it would seem) if the client name has a / in 
it jack is unable to start the new client.  Would it be possible to fix 
this--I have several ardour sessions that use ardour/ksi as their client 
name, and changing it might screw up routing.  I am willing to fix this in 
current CVS (if necessary) but am wondering what your thoughts are.

_J

-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
Permalink | Reply | 0 comments |
headers
Fernando Pablo Lopez-Lezcano | 3 Apr 2003 03:26
Picon

jack 0.66.3 + qjackconnect 0.0.3b

Anyone out there still getting qjackconnect segfaults using the latest
and greatest jack? I'm using fresh jack cvs (0.66.3) and the latest
qjackconnect I know of (0.0.3b). 

Qjackconnect works fine, connects and disconnects apps and so on and so
forth. Sometimes, when a connected jack application quits (a normal
exit, not a segfault), qjackconnect segfaults (not immediately, after a
while). 

-- Fernando

-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
Permalink | Reply | 2 comments |

Gmane