Menu
▾
▴
Re: [FFADO-devel] enclosed patch: DICE avoid duplicated streaming channel name
|
From: Philippe C. <la-...@or...> - 2012-09-06 20:21:20
|
Le mardi 04 septembre 2012 à 20:25 +0930, Jonathan Woithe a écrit :
> Hi Theo, Phil
>
> On Mon, Sep 03, 2012 at 09:32:33PM +0200, theo gantenbein wrote:
> > @44100 and @48000 jack starts, but I get many xruns. Increasing buffer size
> > doesn't make a difference (perhaps changing IRQ priorities will help, I
> > have to try this).
>
> Many xruns is *usually* a sign that some part of the computer can't keep up.
> You may have mentioned this before, but which firewire interface are you
> using? Also, are you running a PREEMPT kernel?
>
> All this (and much more) is reported in the output from ffado-diag, so if
> you haven't already posted this it would be good if you could do so. In the
> meantime I'll check the list archive in case you already have. :-)
>
> > Below's the output from jackd -P 79 -d firewire -p 128 -n 3 -r 96000 -v 5
>
> Again, this is suffering from the same apparent problem as with 88200.
> You've requested 96 kHz operation but the interface itself still seems to be
> running at 48 kHz:
>
> > putPacket: Instantanous samplerate more than 1% off nominal.
> > [Nom fs: 96000.000000, Instantanous fs: 47994.141340, diff: 48005.858660
>
> It's as if it's getting the base rate correct but is missing the multiplier
> (which is 2x in this case).
>
> Any thoughts Phil?
>
> Regards
> jonathan
Hi Theo, Jonathan and Adrian,
Well, since I have no information about DICE specification (if anybody
has something about, it will be welcome), I compared the outputs of my
Saffire Pro 40 (which will work at 88200) to the one given by Theo with
Liquid Saffire 56 (which will not work neither at 88200 nor 96000), in
similar situation (imposing a samplerate different from the one in the
rom).
There are a lot of points I'm wondering about.
During the discovery of the device, before any samplerate change is
introduced:
Pro 40
1346870392587126: (dice_avdevice.cpp)[ 671] showDevice: Nick
name : Pro40
1346870392588706: (dice_avdevice.cpp)[ 675] showDevice: Clock
Select : 0x02 0x0C
1346870392590026: (dice_avdevice.cpp)[ 679] showDevice:
Enable : false
1346870392591630: (dice_avdevice.cpp)[ 683] showDevice: Clock
Status : locked 0x02
1346870392592978: (dice_avdevice.cpp)[ 686] showDevice: Extended
Status : 0x00000000
1346870392594840: (dice_avdevice.cpp)[ 689] showDevice:
Samplerate : 0x0000BB80 (48000)
At that point, for Pro 40:
clock is set to 0x02 and is found to be "locked" at this value.
0x02 is for samplerate 48000 (the default sample rate when Saffire is
powered on); this is coherent with samplerate exhibited after.
Liquid 56
1346699006701303: (dice_avdevice.cpp)[ 671] showDevice: Nick
name : Liquid56-0016ef
1346699006703048: (dice_avdevice.cpp)[ 675] showDevice: Clock
Select : 0x02 0x0C
1346699006704759: (dice_avdevice.cpp)[ 679] showDevice:
Enable : false
1346699006706024: (dice_avdevice.cpp)[ 683] showDevice: Clock
Status : locked 0x03
1346699006707783: (dice_avdevice.cpp)[ 686] showDevice: Extended
Status : 0x00000000
1346699006710440: (dice_avdevice.cpp)[ 689] showDevice:
Samplerate : 0x00015888 (88200)
Here:
clock is set to 0x02 (48000) but locked at 0x03 (88200)
samplerate is marked as 88200 (coherent with the Clock Status not
with the Clock Select)
This is somewhat strange or, at least,
unexpected.
After applying the samplerate change
1346699006777562: (dice_avdevice.cpp)[ 270] setSamplingFrequency:
Setting sample rate: 96000
...
Pro 40 (imposed sample rate 88200, not 96000, since Pro 40 does not
work well at 96000)
1346870392720983: (dice_avdevice.cpp)[ 671] showDevice: Nick
name : Pro40
1346870392722586: (dice_avdevice.cpp)[ 675] showDevice: Clock
Select : 0x03 0x0C
1346870392723939: (dice_avdevice.cpp)[ 679] showDevice:
Enable : false
1346870392726725: (dice_avdevice.cpp)[ 683] showDevice: Clock
Status : not locked 0x02
1346870392728108: (dice_avdevice.cpp)[ 686] showDevice: Extended
Status : 0x00000000
1346870392729705: (dice_avdevice.cpp)[ 689] showDevice:
Samplerate : 0x0000BB80 (48000)
Clock Select is correct (0x03 <-> 88200) but clock is not locked and
sample rate is marked as 48000 (<-> 0x02)
At that point I am somewhat wondering; Jack will start and Pro 40 will
work correctly.
But is this the correct behaviour or:
- would we have to await for a while until the hardware lock the
clock ?
- or impose to lock the clock at the correct values ?
- something else ?
I will have a trial probably this week end, trying to wait for a while
and see if the output is different.
Liquid 56
1346699006839856: (dice_avdevice.cpp)[ 671] showDevice: Nick
name : Liquid56-0016ef
1346699006841378: (dice_avdevice.cpp)[ 675] showDevice: Clock
Select : 0x04 0x0C
1346699006842791: (dice_avdevice.cpp)[ 679] showDevice:
Enable : false
1346699006844163: (dice_avdevice.cpp)[ 683] showDevice: Clock
Status : not locked 0x03
1346699006845865: (dice_avdevice.cpp)[ 686] showDevice: Extended
Status : 0x00000000
1346699006847086: (dice_avdevice.cpp)[ 689] showDevice:
Samplerate : 0x00015888 (88200)
This is essentially the same behaviour than for Pro 40.
Next, for both devices, the transmitter and receiver description appears
correct (I just checked on the user manual of Liquid 56/ I have no more
information).
Then the output for Liquid 56 complains
1346699006986653: Warning (dice_avdevice.cpp)[ 871] prepareSP: The
audio channel name vector is incorrect, using default names
each time that prepareSP is called.
But this is (almost surely) because Liquid 56 is an EAP device, using
the generic configuration which does not match the reality (it will be
possible to write specific configuration functions as for Pro 24 and Pro
40); the only consequence is that channel names will be input_... and
output_....
Then both complains
1346699007095095: Warning (StreamProcessor.cpp)[1708] updateState:
ignoring identity state update from/to ePS_Created
I have no idea what it is about.
Then, an interesting point is that Pro 40 output is:
1346870394194297: Warning (StreamProcessor.cpp)[ 798] getPacket:
Instantanous samplerate more than 1% off nominal. [Nom fs: 88200.000000,
Instantaneous fs: 44087.453750, diff: 44112.546250 ( 0.500142)]
ffado_streaming_wait
============================================
Xruns: 0
============================================
----------------------------------------------------
Dumping StreamProcessorManager information...
...
while Liquid 56 repeats further times:
1346699007439473: Warning (StreamProcessor.cpp)[ 479] putPacket:
Instantanous samplerate more than 1% off nominal. [Nom fs: 96000.000000,
Instantanous fs: 47994.141340, diff: 48005.858660 ( 0.500061)]
1346699007439514: Debug (StreamProcessor.cpp)[ 534] putPacket:
(0x18a4a30) Correcting timestamp for dropped cycles, discarding
packet...
1346699007445790: Warning (StreamProcessor.cpp)[ 479] putPacket:
Instantanous samplerate more than 1% off nominal. [Nom fs: 96000.000000,
Instantanous fs: 47988.284110, diff: 48011.715890 ( 0.500122)]
1346699007445805: Debug (StreamProcessor.cpp)[ 534] putPacket:
(0x18a4a30) Correcting timestamp for dropped cycles, discarding
packet...
...
...
1346699007737044: Debug (StreamProcessor.cpp)[ 534] putPacket:
(0x18a4a30) Correcting timestamp for dropped cycles, discarding
packet...
1346699007738032: Debug (StreamProcessorManager.cpp)[1401]
waitForPeriod: Xrun on RECV SP 0x18a4a30 due to ISO side xrun
StreamProcessor 0x18a4a30, Receive:
Port, Channel : 0, 1
Packets, Dropped, Skipped : 2485, 33, 0
Now : 02440771244 (099s 2521c 2732t)
Xrun? : True
State : ePS_DryRunning
Buffer : 0x18a4c70
Framerate : Nominal: 96000, Sync: 95990.857042, Buffer
96000.000000
TimestampedBuffer (0x18a4c70): 0000 frames, 0000 events
Timestamps : head: 2440764805.000, Tail: 2440764805.000,
Next tail: 2440768901.000
Head - Tail : 0.000 (0.000000 frames)
DLL Rate : 4096.000000 (256.000000)
DLL Bandwidth : 4.069011e-09 1/ticks (0.100000 Hz)
1346699007738277: Debug (StreamProcessorManager.cpp)[1406]
waitForPeriod: Xrun on RECV SP 0x18a4a30 due to buffer side xrun
StreamProcessor 0x18a4a30, Receive:
Port, Channel : 0, 1
Packets, Dropped, Skipped : 2490, 33, 0
Now : 02440776900 (099s 2523c 2244t)
Xrun? : True
State : ePS_DryRunning
Buffer : 0x18a4c70
Framerate : Nominal: 96000, Sync: 95990.857042, Buffer
96000.000000
TimestampedBuffer (0x18a4c70): 0000 frames, 0000 events
Timestamps : head: 2440781191.000, Tail: 2440781191.000,
Next tail: 2440785287.000
Head - Tail : 0.000 (0.000000 frames)
DLL Rate : 4096.000000 (256.000000)
DLL Bandwidth : 4.069011e-09 1/ticks (0.100000 Hz)
reporting xruns which apparently prevent any possibility of
synchronization (but I'm fairly unsure of this ...).
As Theo experience many xruns appearance at low samplerate (44.1-48kHz),
that might be the source of the problem; so, Theo, I recommend you to do
all your best to first try to eliminate - almost - all xruns at low
samplerate (Jonathan gaves you some indications).
>From my own side, I will do some test to see if some warning could be
eliminated: I know that Saffire are somewhat lazy at start-up, so
possibly they need some time (I mean ffado would to await for hardware)
to set up correctly.
Now, help or suggestions from everybody are welcome !
Regards,
Phil
--
Philippe Carriere <la-...@or...>
|