Ticket #338 (new bug)

Opened 13 years ago

Last modified 11 years ago

Tascam IF-FW/DM unstable behavior

Reported by: yellius Assigned to:
Priority: waiting for device info Milestone: Indeterminant (need device info)
Component: devices/bebob Version: FFADO SVN (trunk)
Keywords: unstable, tascam, iffwdm Cc:
The device the bug applies to: Tascam IF-FW/DM

Description

Tascam IF-FW/DM support is 'experimental' at this time.

After modifying the udev rules to make the Tascam recognised as a ffado device (see ffado devices page comment), I did not manage to get the driver to work consistently. Some starts of jackd work and others don't. Also the working sessions do experience some XRuns, maybe once every minute or so.

I have attached two logfiles, created with the SVN trunk checkout of 10/7/2011 (compiled with DEBUG=True), using:
jackd --verbose -d firewire -v6 -r 48000 > logfile 2>&1

So all output (standard and errors) are in the log files. One file is of a working session and one of a failed session for comparison.

I have never looked at the bebob/ffado code before and have no logfiles of working cards to compare, but it appears the driver complains about rather large timing differences between expected and actual.

I am happy to try other settings and generate other log files, or help in any other way I can, but I must admit my coding skills have become somewhat rusty.

Many thanks for any help you can give! It would be great if we can get the Tascam to work properly, as they regularly appear on ebay and are great value!

Attachments

working.txt (1.6 MB) - added by yellius on 07/09/11 09:36:34.
Jack session log that works
hang1.txt (1.3 MB) - added by yellius on 07/09/11 09:38:11.
Jack session log that failed
tascam.patch (393 bytes) - added by yellius on 07/31/11 10:41:00.
Tascam IF-FW/DM patch for 'configuration' file
hang-CMP-fail-1.txt (109.9 kB) - added by yellius on 09/24/11 07:51:38.
CMP fails
hang-xrun-1.txt (1.5 MB) - added by yellius on 09/24/11 07:52:42.
XRUN during init
working-1.txt (153.2 kB) - added by yellius on 09/24/11 07:53:04.
Working, sync issues during init

Change History

07/09/11 09:36:34 changed by yellius

  • attachment working.txt added.

Jack session log that works

07/09/11 09:38:11 changed by yellius

  • attachment hang1.txt added.

Jack session log that failed

07/09/11 10:00:20 changed by yellius

Looking more in depth at the log files, it seems the difference between the working and failed sessions is a complaint about a mismatch in the instantaneous sample rate:

Working [line 1196]:
16120951091: Warning (StreamProcessor?.cpp)[ 392] putPacket: Instantanous samplerate more than 1% off nominal. [Nom fs: 48000.000000, Instantanous fs: 38392.501465, diff: 9607.498535 ( 0.200156)]
16120951121: Debug (StreamProcessor.cpp)[ 404] putPacket: cy 0017 rather large TSP difference TS=00589881837 => TS=00589886958 (5121, nom 4096)
16120951174: Warning (StreamProcessor?.cpp)[ 392] putPacket: Instantanous samplerate more than 1% off nominal. [Nom fs: 48000.000000, Instantanous fs: 16000.000000, diff: 32000.000000 ( 0.666667)]
16120951198: Debug (StreamProcessor.cpp)[ 404] putPacket: cy 0027 rather large TSP difference TS=00589903342 => TS=00589915630 (12288, nom 4103)
16120951234: Warning (TimestampedBuffer?.cpp)[1062] incrementFrameCounter: (0x1eb3470) difference rather large (+): diff= 8184.625, max= 1536.000, 589915630.000, 589907445.375
16120951266: Debug (StreamProcessor.cpp)[ 404] putPacket: cy 0028 rather large TSP difference TS=00589915630 => TS=00589919726 (4096, nom 4163)
16120951298: Debug (StreamProcessor?.cpp)[ 404] putPacket: cy 0029 rather large TSP difference TS=00589919726 => TS=00589923822 (4096, nom 4163)
16120951314: Debug (StreamProcessor?.cpp)[ 404] putPacket: cy 0031 rather large TSP difference TS=00589923822 => TS=00589927918 (4096, nom 4162)
16120951350: Debug (StreamProcessor?.cpp)[ 404] putPacket: cy 0032 rather large TSP difference TS=00589927918 => TS=00589932014 (4096, nom 4162)
16120951365: Debug (StreamProcessor?.cpp)[ 404] putPacket: cy 0033 rather large TSP difference TS=00589932014 => TS=00589936111 (4097, nom 4161)

While for the failed session [line 1156]:
16004944147: Warning (StreamProcessor?.cpp)[ 392] putPacket: Instantanous samplerate more than 1% off nominal. [Nom fs: 48000.000000, Instantanous fs: 16000.000000, diff: 32000.000000 ( 0.666667)]
16004944166: Debug (StreamProcessor.cpp)[ 404] putPacket: cy 0017 rather large TSP difference TS=00884784985 => TS=00884797273 (12288, nom 4096)
16004944191: Warning (StreamProcessor?.cpp)[ 392] putPacket: Instantanous samplerate more than 1% off nominal. [Nom fs: 48000.000000, Instantanous fs: 16000.000000, diff: 32000.000000 ( 0.666667)]
16004944207: Debug (StreamProcessor.cpp)[ 404] putPacket: cy 0021 rather large TSP difference TS=00884797273 => TS=00884809561 (12288, nom 4096)
16004944231: Warning (StreamProcessor?.cpp)[ 392] putPacket: Instantanous samplerate more than 1% off nominal. [Nom fs: 48000.000000, Instantanous fs: 16000.000000, diff: 32000.000000 ( 0.666667)]
16004944247: Debug (StreamProcessor.cpp)[ 404] putPacket: cy 0025 rather large TSP difference TS=00884809561 => TS=00884821849 (12288, nom 4096)

I.e. for the working session the instantaneous samplerate mismatch goes away after the first two complaints (after incrementFrameCounter), while for the failed session incrementFrameCounter is NOT shown and the instantaneous samplerate mismatches keep coming up.

Hope this helps..!

(follow-up: ↓ 7 ) 07/23/11 02:54:52 changed by yellius

I have spent some more time on this, trying to get it to work more stably. This is what I previously posted as a comment to the ffado-devices list, but it is not approved yet:

Edit your /lib/udev/rules.d/60-ffado.rules to include the tascam (believe this is Debian based distro specific): SUBSYSTEM!="firewire", GOTO="ffado_end"

ATTR{vendor}=="0x000166", GROUP="audio", ENV{ID_FFADO}="1" # TC GROUP A/S ATTR{vendor}=="0x0001f2", GROUP="audio", ENV{ID_FFADO}="1" # Mark of the Unicorn, Inc. ATTR{vendor}=="0x0003db", GROUP="audio", ENV{ID_FFADO}="1" # Apogee Electronics Corp. ATTR{vendor}=="0x000595", GROUP="audio", ENV{ID_FFADO}="1" # Alesis Corporation ATTR{vendor}=="0x0007f5", GROUP="audio", ENV{ID_FFADO}="1" # Bridgeco Co AG ATTR{vendor}=="0x000a92", GROUP="audio", ENV{ID_FFADO}="1" # Presonus Corporation ATTR{vendor}=="0x000aac", GROUP="audio", ENV{ID_FFADO}="1" # TerraTec? Electronic GmbH ATTR{vendor}=="0x000d6c", GROUP="audio", ENV{ID_FFADO}="1" # M-Audio ATTR{vendor}=="0x000f1b", GROUP="audio", ENV{ID_FFADO}="1" # Ego Systems Inc. ATTR{vendor}=="0x000ff2", GROUP="audio", ENV{ID_FFADO}="1" # Loud Technologies Inc. ATTR{vendor}=="0x001260", GROUP="audio", ENV{ID_FFADO}="1" # Stanton Magnetics,inc. ATTR{vendor}=="0x00130e", GROUP="audio", ENV{ID_FFADO}="1" # Focusrite Audio Engineering Limited ATTR{vendor}=="0x001486", GROUP="audio", ENV{ID_FFADO}="1" # Echo Digital Audio Corporation ATTR{vendor}=="0x001564", GROUP="audio", ENV{ID_FFADO}="1" # BEHRINGER Spezielle Studiotechnik GmbH ATTR{vendor}=="0x001c2d", GROUP="audio", ENV{ID_FFADO}="1" # FlexRadio? Systems ATTR{vendor}=="0x001c6a", GROUP="audio", ENV{ID_FFADO}="1" # Weiss Engineering Ltd. ATTR{vendor}=="0x0040ab", GROUP="audio", ENV{ID_FFADO}="1" # ROLAND DG CORPORATION ATTR{vendor}=="0x010065", GROUP="audio", ENV{ID_FFADO}="1" # TASCAM

# The devices below abuse another Vendor's ID, and therefore we need more advanced rules for those.

ATTR{vendor}=="0x00000a", ATTR{model}=="0x030000", ATTR{units}=="*0x00a02d:0x010001*", GROUP="audio", ENV{ID_FFADO}="1" # CME, Matrix K FW ATTR{vendor}=="0x00000f", ATTR{model}=="0x01006?", ATTR{units}=="*0x00a02d:0x010001*", GROUP="audio", ENV{ID_FFADO}="1" # Mackie, Onyx Firewire ATTR{vendor}=="0x000a35", ATTR{units}=="0x000a35:0x00000[12]", GROUP="audio", ENV{ID_FFADO}="1" # RME

LABEL="ffado_end"

This will enable auto loading. Also, when compiling ffado from source, be sure to edit the configuration file:

device_definitions = ( { # Added by yellius

vendorid = 0x0022E; modelid = 0x10067; vendorname = "Tascam"; modelname = "IFFWDM"; driver = 1; # BeBoB

}, { # Added by yellius

vendorid = 0x10065; modelid = 0x10067; vendorname = "Tascam"; modelname = "IFFWDM"; driver = 1; # BeBoB

},

I have added two different entries, since "ffado-test ListDevices?" and the /sys/bus/firewire* files give different values and I am not sure which one to use. Believe the latter should be correct for the Juju stack.

Finally I have just installed kernel 3.0, as the Juju stack has a longer split-timeout build in (see the release notes here: ), which should help for some devices.

I have also been looking at some of the code, and the papers in the dev section are very useful to get up to speed quickly.

07/23/11 09:32:14 changed by yellius

Update: the 3.0 kernel is significantly more stable! Looking at the release notes, the same probably holds for 2.6.39 (increase in SLIT_TIMEOUT).

From the number of starts I have had now, it seems that at every reboot (both PC and Tascam) a successful Jack session can be started, with virtually no xruns at a buffer of 256. However after killing jack (normal end does not work), it takes a lot of fiddling before you get another good launch.

Developers: I have not submitted patches/diffs before; what is the best way to submit the changes I made to the configuration file?

07/23/11 10:17:55 changed by adi

Hi yellius!

You could simply send the patches to the devel-ml or attach them to this ticket (write something, too, to make us aware there are patches).

If you're familiar with git, I guess it's easiest to see http://repo.or.cz/w/ffado.git and commit to the mob branch. I'll then merge it to the master branch after reviewing it.

Cheers

07/23/11 11:14:46 changed by yellius

Hi Adi,

Thanks for the hint. Are the mob and master gits different from the svn? Please find the patch (against mob) for the configuration file attached, adding support for the 24 ch in/24 ch out/2 midi in/2 midi out Tascam IF-FW/DM.

Unfortunately I have not extracted the AvcModel? yet (see ticket 340).

Cheers,

yellius

PS: For those behind nasty firewalls like me, you can use: git clone http://repo.or.cz/r/ffado.git mob

to clone the mob branch.

07/23/11 12:03:40 changed by adi

TNX.

JFTR, you can *push* to the mob branch, that's what it is for. Anyone can, just push to ssh://mob@repo.or.cz/srv/git/ffado.git

Cheers

(in reply to: ↑ 2 ; follow-up: ↓ 8 ) 07/26/11 06:41:37 changed by stefanr

Replying to yellius:

I have spent some more time on this, trying to get it to work more stably. This is what I previously posted as a comment to the ffado-devices list, but it is not approved yet: Edit your /lib/udev/rules.d/60-ffado.rules to include the tascam (believe this is Debian based distro specific):

There is no extra udev rule necessary for this device on typical Linux distributions. Its Configuration ROM features an AV/C unit directory. (See ticket 340.) Hence stock udev rules will assign "video" group ownership to this device file. On many distributions, normal user accounts are member of the video group.

I have added two different entries, since "ffado-test ListDevices??" and the /sys/bus/firewire* files give different values and I am not sure which one to use. Believe the latter should be correct for the Juju stack.

The udev rule that you suggested relies on the /sys/bus/firewire/devices/fw*/vendor file.

(in reply to: ↑ 7 ) 07/26/11 06:53:43 changed by stefanr

Replying to stefanr:

Replying to yellius:

I have added two different entries, since "ffado-test ListDevices??" and the /sys/bus/firewire* files give different values and I am not sure which one to use. Believe the latter should be correct for the Juju stack.

The udev rule that you suggested relies on the /sys/bus/firewire/devices/fw*/vendor file.

Oops, the two entries were for libffado/configuration, not udev. FFADO apparently uses 0x0022E according to http://subversion.ffado.org/ticket/340#comment:4 --- but you can find out yourself by looking for "getDeviceSetting" and "showSetting" lines in ffado-test Discover output.

07/31/11 10:41:00 changed by yellius

  • attachment tascam.patch added.

Tascam IF-FW/DM patch for 'configuration' file

07/31/11 10:45:26 changed by yellius

Hi! I have updated the patch to use 0x0022E, now against SVN 1990. Unfortunately the proxy I am behind blocks the ssh port, so I can't push into the mob repro...

As mentioned, the 3.0 linux kernel is more stable with ffado (increase in SLIT_TIMEOUT), so I will update this ticket with new succes/hang outputs as I gather and try to analyze them.

09/24/11 07:51:01 changed by yellius

Hi all,

Today was a bad day, ffado did not want to start, so I decided to gather some more outputs.

These files are attached:

hang-CMP-fail-1.txt

Error seems to be: 02311331239: Error (ieee1394service.cpp)[1415] allocateIsoChannelCMP: Could not do CMP from FFC0:00 to FFC1:-1

hang-xrun-1.txt

Errors seems an unhandled XRUN, however during init/start-up

working-1.txt

This one was working, however you can see sync issues during init:

03523813747: Warning (StreamProcessor?.cpp)[ 392] putPacket: Instantanous samplerate more than 1% off nominal. [Nom fs: 48000.000000, Instantanous fs: 16000.000000, diff: 32000.000000 ( 0.666667)]

To me, the differences in samplerate suggest a factor of 3, but I am not sure where this would come from.

Hope someone can take some time to look at these! Please let me know if I can provide more info.

Best regards,

yellius

09/24/11 07:51:38 changed by yellius

  • attachment hang-CMP-fail-1.txt added.

CMP fails

09/24/11 07:52:42 changed by yellius

  • attachment hang-xrun-1.txt added.

XRUN during init

09/24/11 07:53:04 changed by yellius

  • attachment working-1.txt added.

Working, sync issues during init

(follow-up: ↓ 12 ) 04/14/12 05:57:49 changed by jwoithe

This ticket is somewhat related to ticket #340. I have applied the configuration patch (tascam.patch) from yellius to trunk (see r2118). It's unclear to me whether anything else needs to be done here. From the last comments added it seems that there is still a problem and that this might also be tied in with ticket #340. Is there anything more that can be done at this stage?

(in reply to: ↑ 11 ) 04/14/12 10:26:48 changed by yellius

jwoithe,

I can provide some update with my experiences. As explained in the ticket, the difficulty is to get the driver to start. It seems to be related to timing issues, judging from the reported errors. I have to try and start jack a varying number of times (sometimes only once, sometimes tens of times) since the starts often fail with one of the attached errors. Nevertheless once start-up is achieved, the driver is very stable and running smoothly.

I am more of a musician than coder, but have tried to understand the ffado file structure and added some of my own debugging output to try and tackle the issue. I suspect that the DDL may be involved and feel the issue should be solvable, because of the ratio's of actual versus expected sample rates (see error reports and earlier analysis). Once I find some more time I may try again to find the right point to start adjusting, but any other ideas or thoughts are very welcome.

Also, if I can do further tests/reports please let me know, I am very willing to help.

04/21/12 07:17:10 changed by jwoithe

At this point in time I don't know what the next steps might be, beyond stating the obvious that more testing and debugging is needed. To be of much use I will have to read up on the Bebob protocol and how it works. Even then, it is unlikely that I'll be able to contribute much code towards fixing this issue because I don't own the device in question, which will slow debugging down to the point where it becomes prohibitively inefficient.

You are right in that timing issues may originate in the DLL. However, the CMP-related errors are more closely associated with the protocol itself, so there may be a problem with the way FFADO manipulates the device. Or of course there could be more than one problem contributing the symptoms. The fact that the device sometimes works could also point to something as obscure as uninitialised memory, although it's curious that apparently the Tascam is the only device that's this sensitive to whatever the issue may be.

06/01/12 04:43:25 changed by jwoithe

yellius: It may be useful for you to post the output produced by the ffado-diag program on your system just in case there's an obvious cause for the instability you've reported.

08/24/12 05:26:30 changed by jwoithe

  • milestone changed from FFADO 2.1 to FFADO 2.2.

Bumping milestone to 2.2 for the moment. To progress this further, more testing and experimentation will be required by people with access to this device. It should not block the release of FFADO 2.1.

10/30/12 04:11:03 changed by jwoithe

  • priority changed from major to waiting for device info.
  • version changed from FFADO SVN (trunk) to FFADO 2.1.0.
  • milestone changed from FFADO 2.2 to Indeterminant (need device info).

To make progress with this ticket we will require someone with access to a Tascam IF-FW/DM to run tests, carry out debugging and attempt to work out what might be going wrong within FFADO when driving this device. Milestone and priority set accordingly.

10/30/12 04:11:27 changed by jwoithe

  • version changed from FFADO 2.1.0 to FFADO SVN (trunk).