[Jackit-devel] jackd core dump w/ FA-66

Hi all,

I've been having a very regular problem with jack and my Edirol FA-66.
The problem was on Ubuntu Feisty (Jack 0.102.0), and persists on
Ubuntu Gutsy (Jack 0.103.0). Basically everything will work for a
while and then it will crash. Sometimes it works all day without
crashing, other times it will crash immediately. Sometimes reloading
the raw1394 module and restarting jackd will get it running again.

The FA-66 is plugged into a small firewire input and is powered by an
external supply, not over firewire.

The output on crash is usually something like this (I think the number
before "Aborted" varies:

$ ./.jackdrc
jackd 0.103.0
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details

JACK compiled with System V SHM support.
loading driver ..
Freebob using Firewire port 0, node -1
libiec61883 warning: Established connection on channel 0.
You may need to manually set the channel on the receiving node.
libiec61883 warning: Established connection on channel 1.
You may need to manually set the channel on the transmitting node.
./.jackdrc: line 1:  7091 Aborted                 (core dumped) jackd

Re: [Jackit-devel] jackd core dump w/ FA-66

> Basically everything will work for a
> while and then it will crash. Sometimes it works all day without
> crashing, other times it will crash immediately. Sometimes reloading
> the raw1394 module and restarting jackd will get it running again.

Could you check the kernel messages (dmesg)? And also check the firewire
chipset in your computer (lspci -v).

daniel

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

Re: [Jackit-devel] jackd core dump w/ FA-66

On 12/1/07, Daniel Wagner <wagi <at> monom.org> wrote:
> > Basically everything will work for a
> > while and then it will crash. Sometimes it works all day without
> > crashing, other times it will crash immediately. Sometimes reloading
> > the raw1394 module and restarting jackd will get it running again.
>
> Could you check the kernel messages (dmesg)? And also check the firewire
> chipset in your computer (lspci -v).

Sure:

$ dmesg
<snip>
[  175.952817] ipw3945: Error sending cmd #07 to daemon: time out after 500ms.
[ 1324.762525] ohci1394: fw-host0: Unrecoverable error!
[ 1324.762556] ohci1394: fw-host0: Iso Xmit 0 Context died:
ctrl[20649806] cmdptr[f000e2c3]

$ lspci -v
<snip>
03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller
(prog-if 10 [OHCI])
        Subsystem: Dell Unknown device 01cd
        Flags: bus master, medium devsel, latency 64, IRQ 18
        Memory at dcbfd800 (32-bit, non-prefetchable) [size=2K]
        Capabilities: <access denied>
<schnap>

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper

Re: [Jackit-devel] jackd core dump w/ FA-66

I. E. Smith-Heisters wrote:
> On 12/1/07, Daniel Wagner <wagi <at> monom.org> wrote:
>>> Basically everything will work for a
>>> while and then it will crash. Sometimes it works all day without
>>> crashing, other times it will crash immediately. Sometimes reloading
>>> the raw1394 module and restarting jackd will get it running again.
>> Could you check the kernel messages (dmesg)? And also check the firewire
>> chipset in your computer (lspci -v).
> 
> Sure:
> 
> $ dmesg
> <snip>
> [  175.952817] ipw3945: Error sending cmd #07 to daemon: time out after 500ms.
> [ 1324.762525] ohci1394: fw-host0: Unrecoverable error!
> [ 1324.762556] ohci1394: fw-host0: Iso Xmit 0 Context died:
> ctrl[20649806] cmdptr[f000e2c3]

There we have it: the transfer between device and PC stops working. So 
this is not a jackd problem at all.

> $ lspci -v
> <snip>
> 03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller
> (prog-if 10 [OHCI])
>         Subsystem: Dell Unknown device 01cd
>         Flags: bus master, medium devsel, latency 64, IRQ 18
>         Memory at dcbfd800 (32-bit, non-prefetchable) [size=2K]
>         Capabilities: <access denied>
> <schnap>

Re: [Jackit-devel] jackd core dump w/ FA-66

Daniel Wagner wrote:
> I. E. Smith-Heisters wrote:
>> On 12/1/07, Daniel Wagner <wagi <at> monom.org> wrote:
>>>> Basically everything will work for a
>>>> while and then it will crash. Sometimes it works all day without
>>>> crashing, other times it will crash immediately. Sometimes reloading
>>>> the raw1394 module and restarting jackd will get it running again.
>>> Could you check the kernel messages (dmesg)? And also check the firewire
>>> chipset in your computer (lspci -v).
>> Sure:
>>
>> $ dmesg
>> <snip>
>> [  175.952817] ipw3945: Error sending cmd #07 to daemon: time out after 500ms.
>> [ 1324.762525] ohci1394: fw-host0: Unrecoverable error!
>> [ 1324.762556] ohci1394: fw-host0: Iso Xmit 0 Context died:
>> ctrl[20649806] cmdptr[f000e2c3]
> 
> There we have it: the transfer between device and PC stops working. So 
> this is not a jackd problem at all.
> 
>> $ lspci -v
>> <snip>
>> 03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller
>> (prog-if 10 [OHCI])
>>         Subsystem: Dell Unknown device 01cd
>>         Flags: bus master, medium devsel, latency 64, IRQ 18
>>         Memory at dcbfd800 (32-bit, non-prefetchable) [size=2K]
>>         Capabilities: <access denied>
>> <schnap>

Re: [Jackit-devel] jackd core dump w/ FA-66

On 12/2/07, Daniel Wagner <wagi <at> monom.org> wrote:
> I. E. Smith-Heisters wrote:
> > On 12/1/07, Daniel Wagner <wagi <at> monom.org> wrote:
> >>> Basically everything will work for a
> >>> while and then it will crash. Sometimes it works all day without
> >>> crashing, other times it will crash immediately. Sometimes reloading
> >>> the raw1394 module and restarting jackd will get it running again.
> >> Could you check the kernel messages (dmesg)? And also check the firewire
> >> chipset in your computer (lspci -v).
> >
> > Sure:
> >
> > $ dmesg
> > <snip>
> > [  175.952817] ipw3945: Error sending cmd #07 to daemon: time out after 500ms.
> > [ 1324.762525] ohci1394: fw-host0: Unrecoverable error!
> > [ 1324.762556] ohci1394: fw-host0: Iso Xmit 0 Context died:
> > ctrl[20649806] cmdptr[f000e2c3]
>
> There we have it: the transfer between device and PC stops working. So
> this is not a jackd problem at all.
>
> > $ lspci -v
> > <snip>
> > 03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller
> > (prog-if 10 [OHCI])
> >         Subsystem: Dell Unknown device 01cd
> >         Flags: bus master, medium devsel, latency 64, IRQ 18
> >         Memory at dcbfd800 (32-bit, non-prefetchable) [size=2K]
> >         Capabilities: <access denied>

Re: [Jackit-devel] [PATCH] make jack-transport start at frame zero.

On Wednesday 21 November 2007 12:21:14 Pieter Palmers wrote:
> torbenh <at> gmx.de wrote:
> > On Sat, Sep 08, 2007 at 11:58:48PM +0200, Dominic Sacr? wrote:
> >> On 9/7/07, torbenh <at> gmx.de <torbenh <at> gmx.de> wrote:
> >>> when locating the transport to 0 and starting it,
> >>> the first frame reported by the transport structure will be period size
> >>> and not zero.
> >>>
> >>> But ardour assumes its zero and will lag one period behind.
> >>> resulting in misalignment of beats recorded from hydrogen for example.
> >>>
> >>> this patch fixes it. but paul mentioned there could be some other
> >>> nastieness hiding. i did this fix a month ago, and dont remember very
> >>> well.
> >>
> >> Seems to work perfectly for me with your patch. This is something
> >> that's really been bugging me for a long time...
> >
> > yup. me too.
> > we can finally fix hydrogens transport code now.
> > it still does not support tempo changes...
> >
> > but we need ardour to fill in bbt_offset for this.
>
> Another keepalive message for this patch...
>
> what's the status?

There's still something wrong with jack transport sync. At first this patch 
appeared to fix the sync issues for me, but after some more testing, it seems 

Re: [Jackit-devel] [PATCH] make jack-transport start at frame zero.

On Sunday 02 December 2007, Dominic Sacré wrote:
> > what's the status?
>
> There's still something wrong with jack transport sync. At first this patch
> appeared to fix the sync issues for me, but after some more testing, it
> seems the problem really lies elsewhere.
>
> In fact, with an unpatched jack, I can't reproduce the "transport not
> starting at zero" issue. The first time process() is called after starting
> jack transport, the frame reported by jack_transport_query() is zero. After
> that, it's incremented by periodsize on each process() call, as one would
> expect.
>
> With Torben's patch, jack_transport_query() reports frame zero *twice*,
> before it begins to increase normally.
>
> So, while this patch does fix the issue of clients being off by one period
> (as far as I can tell), I don't think it's the right solution, because now
> there's a little hiccup right after starting transport rolling.

Is this still this old thing?:

http://www.nabble.com/jack-transport-oddness-t11880.html

Sadly the link posted by paul back then doesn't seem to work anymore (spam 
victim?)..

Flo

--

-- 

[Jackit-devel] SVN commit 0.107.6

SVN commit 0.107.6: Correct bug in CoreAudio driver sample rate  
management.

Stephane 

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

[Jackit-devel] sample rates

hello

is there anything speaking against using jack with absurdly high sample
rates? i was playing around with the bt878 adc the other day at rates of
448000 and 896000 Sps, which the alsa driver supports but starting jack
with

jackd -d alsa -d hw:1,1 -r 896000

and the lower one respectively made my box just drop unconscious. thanks for
any comments.

bst, opt

--

-- 
�          �          �          �          o          r          g                     
gpg-key at http://xdv.org/~opt/60B2DA43.asc

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

_______________________________________________
Jackit-devel mailing list
Jackit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-devel