snd_dice: Clicking artifacts with TC StudioKonnekt 48

snd_dice: Clicking artifacts with TC StudioKonnekt 48

[Mathias Buhr]

Hi,

thanks to this group, both of my firewire interfaces are (almost)
working! Big thank you!

While the TC Konnekt 24D works fine (playback and recording), the
StudioKonnekt 48 produces clicking artifacts during playback when using
snd_dice. This interface is working flawless on Windows and on a
Jack/FFADO combination. This artifact occurs in all use cases (alsa via
aplay, pulseaudio and jack) and does not seem to be in recorded streams.
After recording the playback with another device, it looks like the
level of the artifact is scaling with the signal and its interval is
interestingly 256ms. Is there anything I can do to further debug this
issue? Capture firewire packets? I would love to get this device fully
working.

I'm using kernel version 5.5.4 but this issue has been there for a long
time.

Thanks,

Mathias

Re: snd_dice: Clicking artifacts with TC StudioKonnekt 48

[Takashi Sakamoto]

Hi,

On Thu, Feb 20, 2020 at 09:34:02PM +0100, Mathias Buhr wrote:
> Hi,
> 
> thanks to this group, both of my firewire interfaces are (almost)
> working! Big thank you!
> 
> While the TC Konnekt 24D works fine (playback and recording), the
> StudioKonnekt 48 produces clicking artifacts during playback when using
> snd_dice. This interface is working flawless on Windows and on a
> Jack/FFADO combination. This artifact occurs in all use cases (alsa via
> aplay, pulseaudio and jack) and does not seem to be in recorded streams.
> After recording the playback with another device, it looks like the
> level of the artifact is scaling with the signal and its interval is
> interestingly 256ms. Is there anything I can do to further debug this
> issue? Capture firewire packets? I would love to get this device fully
> working.
> 
> I'm using kernel version 5.5.4 but this issue has been there for a long
> time.
> 
> Thanks,
> 
> Mathias

Yes. ALSA dice driver brings the issue to your unit regardless of XRUNs.
I can see this issue for recent 5 years (so long time).

At present, ALSA dice driver is designed with the expectation that the
devices performs 'clock-recovery' with timestamp in isochronous packets
transmitted by the driver. The driver transfers PCM frames with
timestamps as exactly the same number as configured sampling rate; e.g.
48,000 frames/sec or 44,096/44,104 frames/sec.

However, many devices including yours don't perform it actually. For
example, all of devices from TC Electronics don't perform it:

 - Konnekt 24D (Dice II STD ASIC)
 - Konnekt 8 (Dice II STD ASIC)
 - Konnkt Live (Dice II STD ASIC)
 - Studio Konnekt 48 (DICE II STD and DICE Mini ASICs)
 - Impact Twin (DICE II STD ASIC)
 - Desktop Konnekt 6 (DICE Mini ASIC)
 - Digital Konnekt 32 (DICE II STD)


They work with sampling clock independent of the timestamp from driver.
Thus it's not possible to synchronize multiple devices on the same
IEEE 1394 bus (this is against the 'myth' that the devices can be
synchronized for its internal sampling, but it's the fact).

Instead, the device expects the driver to perform the 'clock-recovery'
and transfer PCM frames as mostly the same as the calculated sampling
rate. Even if the device is configured to handle 48,000 PCM frames per
second, the device actually handles less or more PCM frames; e.g.
47,988, 47,992 or 48,008, 48,016. Unfortunately, current ALSA dice
driver is not designed to work for it. In device internal, it handles
surplus PCM frames or the lack of PCM frames for several seconds, then
causes noisy sound I guess.

The libffado2 is programmed for the 'clock-recovery'. On the other hand,
it includes design mistake to aggregate several types of devices and give
abstracted device to applications such as jackd. When considering the
above design of actual hardware, the design is not good since each actual
hardware works independent sampling clocks.

Anyway, if you're satisfied to libffado2, it's better to continue to use
it. ALSA IEC 61883-1/6 packet streaming engine is completely different
from the one in libffado2. It's the most convenient way to avoid
involvement in such difficult issue which developers have left for a
long time.


Regards

Takashi Sakamoto

Re: snd_dice: Clicking artifacts with TC StudioKonnekt 48

[Mathias Buhr]

Thanks for your reply Takashi! It clarifies the situation. I'lll stick
with ffado then.

Regards,

Mathias

Re: snd_dice: Clicking artifacts with TC StudioKonnekt 48

[Takashi Sakamoto]

Hi,

On Sat, Feb 22, 2020 at 05:49:29PM +0100, Mathias Buhr wrote:
> Thanks for your reply Takashi! It clarifies the situation. I'lll stick
> with ffado then.
> 
> Regards,
> 
> Mathias

Both of libffado2 and ALSA dice driver have problems for each, but it's
a convenient option for users of Dice-based devices to use the former,
at present. I've been improved ALSA dice driver for years with the other
drivers, but it doesn't bring so hasty changes since it's a kind of
reverse-engineering; no one knows the actual design and few ones can
make discussion based on the fact.


Well, I also own TC Electronic Sudio Konnekt 48 and I've investigated
its protocol to configure I/O routings on internal DSP. After my
vacation, I'll send information about it for your convenience
(maybe next week).


Regards

Takashi Sakamoto

Re: snd_dice: Clicking artifacts with TC StudioKonnekt 48

[Mathias Buhr]

On 24.02.20 01:20, Takashi Sakamoto wrote:
> Hi,
>
> On Sat, Feb 22, 2020 at 05:49:29PM +0100, Mathias Buhr wrote:
>> Thanks for your reply Takashi! It clarifies the situation. I'lll stick
>> with ffado then.
>>
>> Regards,
>>
>> Mathias
> Both of libffado2 and ALSA dice driver have problems for each, but it's
> a convenient option for users of Dice-based devices to use the former,
> at present. I've been improved ALSA dice driver for years with the other
> drivers, but it doesn't bring so hasty changes since it's a kind of
> reverse-engineering; no one knows the actual design and few ones can
> make discussion based on the fact.
>
>
> Well, I also own TC Electronic Sudio Konnekt 48 and I've investigated
> its protocol to configure I/O routings on internal DSP. After my
> vacation, I'll send information about it for your convenience
> (maybe next week).
>
>
> Regards
>
> Takashi Sakamoto

Thanks Takashi! I'd appreciate that!

Regards

-Mathias

Re: snd_dice: Clicking artifacts with TC StudioKonnekt 48

[Takashi Sakamoto]

Hi,

On Wed, Feb 26, 2020 at 01:51:53PM +0100, Mathias Buhr wrote:
> On 24.02.20 01:20, Takashi Sakamoto wrote:
> > Hi,
> >
> > On Sat, Feb 22, 2020 at 05:49:29PM +0100, Mathias Buhr wrote:
> >> Thanks for your reply Takashi! It clarifies the situation. I'lll stick
> >> with ffado then.
> >>
> >> Regards,
> >>
> >> Mathias
> > Both of libffado2 and ALSA dice driver have problems for each, but it's
> > a convenient option for users of Dice-based devices to use the former,
> > at present. I've been improved ALSA dice driver for years with the other
> > drivers, but it doesn't bring so hasty changes since it's a kind of
> > reverse-engineering; no one knows the actual design and few ones can
> > make discussion based on the fact.
> >
> >
> > Well, I also own TC Electronic Sudio Konnekt 48 and I've investigated
> > its protocol to configure I/O routings on internal DSP. After my
> > vacation, I'll send information about it for your convenience
> > (maybe next week).
> >
> >
> > Regards
> >
> > Takashi Sakamoto
> 
> Thanks Takashi! I'd appreciate that!

This is my memo about the part of configuration in this model
for analog I/O:

Addr: 0x'ffff'e0a0'13dc
Offset: quadlet: target
- 0x00: 00 00 00 00:
- 0x04: ff ff fc 18:
- 0x08: ff ff fd a8:
- 0x0c: 00 00 00 00:
- 0x10: 00 00 00 01:
- 0x14: 00 00 00 37: main out L source
- 0x18: 00 00 00 00:
- 0x1c: 00 00 00 00:
- 0x20: 00 00 00 38: main out R source
- 0x24: 00 00 00 00:
- 0x28: 00 00 00 00:
- 0x2c: 00 00 00 01:
- 0x30: 00 00 00 37: phones 1 source
- 0x34: 00 00 00 00:
- 0x38: 00 00 00 00:
- 0x3c: 00 00 00 38: phones 2 source
- 0x40: 00 00 00 00:
- 0x44: 00 00 00 00:
- 0x48: 00 00 00 01:
- 0x4c: 00 00 00 37: line 5 source
- 0x50: 00 00 00 00:
- 0x54: 00 00 00 00:
- 0x58: 00 00 00 5a: line 6 source
- 0x5c: 00 00 00 00:
- 0x60: 00 00 00 00:
- 0x64: 00 00 00 01:
- 0x68: 00 00 00 3d: line 7 source
- 0x6c: 00 00 00 00:
- 0x70: 00 00 00 00:
- 0x74: 00 00 00 3e: line 8 source
Values:
- Unused: unused
- Mic/Inst/Line input:0x01-0x0c
- S/PDIF input:       0x0d/0x0e
- ADAT input:         0x0f-0x16
- Stream input:       0x37-0x4e
- Mixer output:       0x55/0x56
- Aux 1 output:       0x57/0x58
- Aux 2 output:       0x59/0x5a
- Reverb output:      0x5b/0x5c

You can configure your device by 'firewire-request' command in
'linux-firewire-utils' repository.
https://github.com/cladisch/linux-firewire-utils

For example, when switching source of main out L from stream-1 to
mic/inst/line input 1:
$ printf %x $((0xffffe0a013dc + 0x14))
0xffffe0a013f0
$ ./firewire-request /dev/fw1 read 0xffffe0a013f0
result: 00000037
$ ./firewire-request /dev/fw1 write 0xffffe0a013f0 0x00000001
$ ./firewire-request /dev/fw1 read 0xffffe0a013f0
result: 00000001


Regards

Takashi Sakamoto

Re: snd_dice: Clicking artifacts with TC StudioKonnekt 48

[Scott Bahling]

Hi Takashi,

On Sat, 2020-02-22 at 10:25 +0900, Takashi Sakamoto wrote:
> Hi,
> 
> On Thu, Feb 20, 2020 at 09:34:02PM +0100, Mathias Buhr wrote:
> > Hi,
> > 
> > thanks to this group, both of my firewire interfaces are (almost)
> > working! Big thank you!
> > 
> > While the TC Konnekt 24D works fine (playback and recording), the
> > StudioKonnekt 48 produces clicking artifacts during playback when using
> > snd_dice. This interface is working flawless on Windows and on a
> > Jack/FFADO combination. This artifact occurs in all use cases (alsa via
> > aplay, pulseaudio and jack) and does not seem to be in recorded streams.
> > After recording the playback with another device, it looks like the
> > level of the artifact is scaling with the signal and its interval is
> > interestingly 256ms. Is there anything I can do to further debug this
> > issue? Capture firewire packets? I would love to get this device fully
> > working.
> > 
> > I'm using kernel version 5.5.4 but this issue has been there for a long
> > time.
> > 
> > Thanks,
> > 
> > Mathias
> 
> Yes. ALSA dice driver brings the issue to your unit regardless of XRUNs.
> I can see this issue for recent 5 years (so long time).
> 
> At present, ALSA dice driver is designed with the expectation that the
> devices performs 'clock-recovery' with timestamp in isochronous packets
> transmitted by the driver. The driver transfers PCM frames with
> timestamps as exactly the same number as configured sampling rate; e.g.
> 48,000 frames/sec or 44,096/44,104 frames/sec.
> 
> However, many devices including yours don't perform it actually. For
> example, all of devices from TC Electronics don't perform it:
> 
>  - Konnekt 24D (Dice II STD ASIC)
>  - Konnekt 8 (Dice II STD ASIC)
>  - Konnkt Live (Dice II STD ASIC)
>  - Studio Konnekt 48 (DICE II STD and DICE Mini ASICs)
>  - Impact Twin (DICE II STD ASIC)
>  - Desktop Konnekt 6 (DICE Mini ASIC)
>  - Digital Konnekt 32 (DICE II STD)
> 
> 
> They work with sampling clock independent of the timestamp from driver.
> Thus it's not possible to synchronize multiple devices on the same
> IEEE 1394 bus (this is against the 'myth' that the devices can be
> synchronized for its internal sampling, but it's the fact).
> 
> Instead, the device expects the driver to perform the 'clock-recovery'
> and transfer PCM frames as mostly the same as the calculated sampling
> rate. Even if the device is configured to handle 48,000 PCM frames per
> second, the device actually handles less or more PCM frames; e.g.
> 47,988, 47,992 or 48,008, 48,016. Unfortunately, current ALSA dice
> driver is not designed to work for it. In device internal, it handles
> surplus PCM frames or the lack of PCM frames for several seconds, then
> causes noisy sound I guess.

I was just about to start a thread related to a very similar issue I'm
seeing with my Tascam FW-1884. But in my case I'm only running one
device/clock source. Could the clock-recovery issue also be affecting a
single FW-1884 device?

In my case I'm witnessing exactly one frame being dropped at a consistent
interval of about 240ms at 96000 frames per second and 480ms at 48000 frames
per second.

> The libffado2 is programmed for the 'clock-recovery'. On the other hand,
> it includes design mistake to aggregate several types of devices and give
> abstracted device to applications such as jackd. When considering the
> above design of actual hardware, the design is not good since each actual
> hardware works independent sampling clocks.

I have not tried FFADO yet. I will see if the issue goes away with FFADO.

Best Regards,

Scott

Re: snd_dice: Clicking artifacts with TC StudioKonnekt 48

[Takashi Sakamoto]

Hi Scott,

On Wed, May 06, 2020 at 05:56:37PM +0200, Scott Bahling wrote:
> Hi Takashi,
> 
> On Sat, 2020-02-22 at 10:25 +0900, Takashi Sakamoto wrote:
> > Hi,
> > 
> > On Thu, Feb 20, 2020 at 09:34:02PM +0100, Mathias Buhr wrote:
> > > Hi,
> > > 
> > > thanks to this group, both of my firewire interfaces are (almost)
> > > working! Big thank you!
> > > 
> > > While the TC Konnekt 24D works fine (playback and recording), the
> > > StudioKonnekt 48 produces clicking artifacts during playback when using
> > > snd_dice. This interface is working flawless on Windows and on a
> > > Jack/FFADO combination. This artifact occurs in all use cases (alsa via
> > > aplay, pulseaudio and jack) and does not seem to be in recorded streams.
> > > After recording the playback with another device, it looks like the
> > > level of the artifact is scaling with the signal and its interval is
> > > interestingly 256ms. Is there anything I can do to further debug this
> > > issue? Capture firewire packets? I would love to get this device fully
> > > working.
> > > 
> > > I'm using kernel version 5.5.4 but this issue has been there for a long
> > > time.
> > > 
> > > Thanks,
> > > 
> > > Mathias
> > 
> > Yes. ALSA dice driver brings the issue to your unit regardless of XRUNs.
> > I can see this issue for recent 5 years (so long time).
> > 
> > At present, ALSA dice driver is designed with the expectation that the
> > devices performs 'clock-recovery' with timestamp in isochronous packets
> > transmitted by the driver. The driver transfers PCM frames with
> > timestamps as exactly the same number as configured sampling rate; e.g.
> > 48,000 frames/sec or 44,096/44,104 frames/sec.
> > 
> > However, many devices including yours don't perform it actually. For
> > example, all of devices from TC Electronics don't perform it:
> > 
> >  - Konnekt 24D (Dice II STD ASIC)
> >  - Konnekt 8 (Dice II STD ASIC)
> >  - Konnkt Live (Dice II STD ASIC)
> >  - Studio Konnekt 48 (DICE II STD and DICE Mini ASICs)
> >  - Impact Twin (DICE II STD ASIC)
> >  - Desktop Konnekt 6 (DICE Mini ASIC)
> >  - Digital Konnekt 32 (DICE II STD)
> > 
> > 
> > They work with sampling clock independent of the timestamp from driver.
> > Thus it's not possible to synchronize multiple devices on the same
> > IEEE 1394 bus (this is against the 'myth' that the devices can be
> > synchronized for its internal sampling, but it's the fact).
> > 
> > Instead, the device expects the driver to perform the 'clock-recovery'
> > and transfer PCM frames as mostly the same as the calculated sampling
> > rate. Even if the device is configured to handle 48,000 PCM frames per
> > second, the device actually handles less or more PCM frames; e.g.
> > 47,988, 47,992 or 48,008, 48,016. Unfortunately, current ALSA dice
> > driver is not designed to work for it. In device internal, it handles
> > surplus PCM frames or the lack of PCM frames for several seconds, then
> > causes noisy sound I guess.
> 
> I was just about to start a thread related to a very similar issue I'm
> seeing with my Tascam FW-1884. But in my case I'm only running one
> device/clock source. Could the clock-recovery issue also be affecting a
> single FW-1884 device?
>
> In my case I'm witnessing exactly one frame being dropped at a consistent
> interval of about 240ms at 96000 frames per second and 480ms at 48000 frames
> per second.

Yes. Below table is the result to parse log of packet streaming from
FW-1884 in 48.0 kHz sampling transfer frequency. The left most column is
the total number of events (=PCM samples) in second, and the middle and
right most are sec and cycle on IEEE 1394 isochronous communication.
You can see the device doesn't transfers as the same packets as the
sampling transfer frequency.

events | sec | cycle
====================
 47998 |  0  | 2817
 47999 |  1  | 2817
 47998 |  2  | 2817
 47999 |  3  | 2817
 47999 |  4  | 2817
 47998 |  5  | 2817
 47999 |  6  | 2817
 47999 |  7  | 2817

It's likely that the gap between 48000 and 47998-47999 causes the drop
frame, because current implementation of ALSA IEC 61883-1/6 packet
streaming engine transfers isochronous packets which includes exactly
the same events as configured sampling transfer frequency.

But here I have a question about your way to confirm the drop. Do you
use any way to loopback analog/digital audio output to input or
something else?

> > The libffado2 is programmed for the 'clock-recovery'. On the other hand,
> > it includes design mistake to aggregate several types of devices and give
> > abstracted device to applications such as jackd. When considering the
> > above design of actual hardware, the design is not good since each actual
> > hardware works independent sampling clocks.
> 
> I have not tried FFADO yet. I will see if the issue goes away with FFADO.

TASCAM FireWire series is not supported by libffado2.


Regards

Takashi Sakamoto

Re: Missing frames on Tascam FW-1884 (was Re: snd_dice: Clicking artifacts with TC StudioKonnekt 48)

[Scott Bahling]

On Thu, 2020-05-07 at 22:38 +0900, Takashi Sakamoto wrote:
> Hi Scott,
> 
> On Wed, May 06, 2020 at 05:56:37PM +0200, Scott Bahling wrote:
> > Hi Takashi,
> > 
> > On Sat, 2020-02-22 at 10:25 +0900, Takashi Sakamoto wrote:
> > > Hi,
> > > 
> > > On Thu, Feb 20, 2020 at 09:34:02PM +0100, Mathias Buhr wrote:
> > > > Hi,
> > > > 
> > > > thanks to this group, both of my firewire interfaces are (almost)
> > > > working! Big thank you!
> > > > 
> > > > While the TC Konnekt 24D works fine (playback and recording), the
> > > > StudioKonnekt 48 produces clicking artifacts during playback when using
> > > > snd_dice. This interface is working flawless on Windows and on a
> > > > Jack/FFADO combination. This artifact occurs in all use cases (alsa via
> > > > aplay, pulseaudio and jack) and does not seem to be in recorded streams.
> > > > After recording the playback with another device, it looks like the
> > > > level of the artifact is scaling with the signal and its interval is
> > > > interestingly 256ms. Is there anything I can do to further debug this
> > > > issue? Capture firewire packets? I would love to get this device fully
> > > > working.
> > > > 
> > > > I'm using kernel version 5.5.4 but this issue has been there for a long
> > > > time.
> > > > 
> > > > Thanks,
> > > > 
> > > > Mathias
> > > 
> > > Yes. ALSA dice driver brings the issue to your unit regardless of XRUNs.
> > > I can see this issue for recent 5 years (so long time).
> > > 
> > > At present, ALSA dice driver is designed with the expectation that the
> > > devices performs 'clock-recovery' with timestamp in isochronous packets
> > > transmitted by the driver. The driver transfers PCM frames with
> > > timestamps as exactly the same number as configured sampling rate; e.g.
> > > 48,000 frames/sec or 44,096/44,104 frames/sec.
> > > 
> > > However, many devices including yours don't perform it actually. For
> > > example, all of devices from TC Electronics don't perform it:
> > > 
> > >  - Konnekt 24D (Dice II STD ASIC)
> > >  - Konnekt 8 (Dice II STD ASIC)
> > >  - Konnkt Live (Dice II STD ASIC)
> > >  - Studio Konnekt 48 (DICE II STD and DICE Mini ASICs)
> > >  - Impact Twin (DICE II STD ASIC)
> > >  - Desktop Konnekt 6 (DICE Mini ASIC)
> > >  - Digital Konnekt 32 (DICE II STD)
> > > 
> > > 
> > > They work with sampling clock independent of the timestamp from driver.
> > > Thus it's not possible to synchronize multiple devices on the same
> > > IEEE 1394 bus (this is against the 'myth' that the devices can be
> > > synchronized for its internal sampling, but it's the fact).
> > > 
> > > Instead, the device expects the driver to perform the 'clock-recovery'
> > > and transfer PCM frames as mostly the same as the calculated sampling
> > > rate. Even if the device is configured to handle 48,000 PCM frames per
> > > second, the device actually handles less or more PCM frames; e.g.
> > > 47,988, 47,992 or 48,008, 48,016. Unfortunately, current ALSA dice
> > > driver is not designed to work for it. In device internal, it handles
> > > surplus PCM frames or the lack of PCM frames for several seconds, then
> > > causes noisy sound I guess.
> > 
> > I was just about to start a thread related to a very similar issue I'm
> > seeing with my Tascam FW-1884. But in my case I'm only running one
> > device/clock source. Could the clock-recovery issue also be affecting a
> > single FW-1884 device?
> > 
> > In my case I'm witnessing exactly one frame being dropped at a consistent
> > interval of about 240ms at 96000 frames per second and 480ms at 48000 frames
> > per second.
> 
> Yes. Below table is the result to parse log of packet streaming from
> FW-1884 in 48.0 kHz sampling transfer frequency. The left most column is
> the total number of events (=PCM samples) in second, and the middle and
> right most are sec and cycle on IEEE 1394 isochronous communication.
> You can see the device doesn't transfers as the same packets as the
> sampling transfer frequency.
> 
> events | sec | cycle
> ====================
>  47998 |  0  | 2817
>  47999 |  1  | 2817
>  47998 |  2  | 2817
>  47999 |  3  | 2817
>  47999 |  4  | 2817
>  47998 |  5  | 2817
>  47999 |  6  | 2817
>  47999 |  7  | 2817

Very interesting. How are you collecting that data? And is this just the
result of the computer clock and the FW-1884 internal clock not being in
sync?

> It's likely that the gap between 48000 and 47998-47999 causes the drop
> frame, because current implementation of ALSA IEC 61883-1/6 packet
> streaming engine transfers isochronous packets which includes exactly
> the same events as configured sampling transfer frequency.
> 
> But here I have a question about your way to confirm the drop. Do you
> use any way to loopback analog/digital audio output to input or
> something else?

I was running a square wave signal from Audacity to the outputs of the FW-
1884 and was interested in the bandwidth and slew rates of the analog chain
by viewing the resulting wave form of the analog out on an oscilloscope. It
was during that testing when I noticed the wave form jumping to the left
periodically. Narrowing in on the distance in time of the waveform shift, it
turned out to be the time of one frame. I also looped the signal back into
an input of the device and recorded the audio in which I then visually
counted samples to verified what I was seeing on the oscilloscope. Also
running that input through the baudline spectrum analyzer it is easy to see
the glitches reliably every ~240ms.

I verified that capture is not affected - I only see the missing sample on
playback.

I tested on another computer and the effect was also there, but the interval
between dropped frames was 100ms longer (~340ms) than on the first computer.

> > > The libffado2 is programmed for the 'clock-recovery'. On the other hand,
> > > it includes design mistake to aggregate several types of devices and give
> > > abstracted device to applications such as jackd. When considering the
> > > above design of actual hardware, the design is not good since each actual
> > > hardware works independent sampling clocks.
> > 
> > I have not tried FFADO yet. I will see if the issue goes away with FFADO.
> 
> TASCAM FireWire series is not supported by libffado2.

Yes, I noticed that right after I sent my email.

Best Regards,

Scott

Re: Missing frames on Tascam FW-1884 (was Re: snd_dice: Clicking artifacts with TC StudioKonnekt 48)

[Takashi Sakamoto]

Hi Scott,

Sorry to be late.

On Thu, May 07, 2020 at 04:41:30PM +0200, Scott Bahling wrote:
> > > I was just about to start a thread related to a very similar issue I'm
> > > seeing with my Tascam FW-1884. But in my case I'm only running one
> > > device/clock source. Could the clock-recovery issue also be affecting a
> > > single FW-1884 device?
> > > 
> > > In my case I'm witnessing exactly one frame being dropped at a consistent
> > > interval of about 240ms at 96000 frames per second and 480ms at 48000 frames
> > > per second.
> > 
> > Yes. Below table is the result to parse log of packet streaming from
> > FW-1884 in 48.0 kHz sampling transfer frequency. The left most column is
> > the total number of events (=PCM samples) in second, and the middle and
> > right most are sec and cycle on IEEE 1394 isochronous communication.
> > You can see the device doesn't transfers as the same packets as the
> > sampling transfer frequency.
> > 
> > events | sec | cycle
> > ====================
> >  47998 |  0  | 2817
> >  47999 |  1  | 2817
> >  47998 |  2  | 2817
> >  47999 |  3  | 2817
> >  47999 |  4  | 2817
> >  47998 |  5  | 2817
> >  47999 |  6  | 2817
> >  47999 |  7  | 2817
> 
> Very interesting. How are you collecting that data? And is this just the
> result of the computer clock and the FW-1884 internal clock not being in
> sync?
 
ALSA IEC 61883-1/6 packet streaming engine have a tracepoints event;
snd_firewire_lib:amdtp_packet. You can get the event log by perf tools
which is a part of Linux kernel source[1] and uses perf_event_open(2)
system call, by trace-cmd tools[2] which uses tracefs, or by operate
nodes on debugfs directly. Then you can calculate with the log for the
above table.

The log looks like:

$ perf record -e snd_firewire_lib:amdtp_packet
(ctl + C)
$ perf report -s time,trace --stdio
...
01 3629 ffc1 ffc0 00 014 06 000 00 1 00 1 2 0 0 144 2 250 0
01 3630 ffc1 ffc0 00 014 06 006 01 1 01 1 2 0 6 144 2 18 0
01 3631 ffc1 ffc0 00 014 06 012 02 1 02 1 2 0 12 144 2 38 0
01 3632 ffc1 ffc0 00 014 06 018 03 1 03 1 2 0 18 144 2 255 255
01 3633 ffc1 ffc0 00 014 06 024 04 1 04 1 2 0 24 144 2 58 0
01 3634 ffc1 ffc0 00 014 06 030 05 1 05 1 2 0 30 144 2 82 0
01 3635 ffc1 ffc0 00 014 06 036 06 1 06 1 2 0 36 144 2 102 0
01 3636 ffc1 ffc0 00 014 06 042 07 1 07 1 2 0 42 144 2 255 255

The legend of each column:

0 (decimal): second part of isoc cycle
1 (decimal): cycle part of isoc cycle
2 (hexadecimal): transmitter node ID
3 (hexadecimal): receiver node ID
4 (decimal): isoc channel
5 (decimal): the number of quadlets in payload
6 (decimal): the number of data blocks in payload
7 (decimal): the total number of data blocks rounded by 0xff
8.. : (omit)

When accumulating the number of data blocks every 8,000 cycles, it
represents the number of data blocks transmitted per second.
'lsfirewirephy' utility in linux-firewire-utils[3] helps you to
distinguish the node ID (0xffcX):

$ lsfirewirephy
bus 0, node 0: 080028:424296  Texas Instruments TSB41AB1/2
bus 0, node 1: 080028:831307  Texas Instruments TSB81BA3E/XIO2213

The accumulated number is effective sampling rate in a view of bus
clock on IEEE 1394, and ALSA IEC 61883-1/6 packet streaming engine
is designed to packetize according to the clock. The engine also
manages ALSA PCM applications for how much PCM frames should be
handled in process time.

Ideally, the effective sampling rate is the same as configured sampling
rate; e.g. 48,000. For playback direction, ALSA IEC 61883-1/6 engine
packetizes with PCM frames as the ideal sampling rate. (If you're
interested in implementation, please see 'calculate_syt_offset()' and
'calculate_data_blocks()' in 'sound/firewire/amdtp-stream.c'[1])

On the other hand, for capture direction, the device doesn't transmit
packets with PCM frames as the ideal sampling rate. The effective
sampling rate is slightly different from the ideal one.

> > It's likely that the gap between 48000 and 47998-47999 causes the drop
> > frame, because current implementation of ALSA IEC 61883-1/6 packet
> > streaming engine transfers isochronous packets which includes exactly
> > the same events as configured sampling transfer frequency.
> > 
> > But here I have a question about your way to confirm the drop. Do you
> > use any way to loopback analog/digital audio output to input or
> > something else?
> 
> I was running a square wave signal from Audacity to the outputs of the FW-
> 1884 and was interested in the bandwidth and slew rates of the analog chain
> by viewing the resulting wave form of the analog out on an oscilloscope. It
> was during that testing when I noticed the wave form jumping to the left
> periodically. Narrowing in on the distance in time of the waveform shift, it
> turned out to be the time of one frame. I also looped the signal back into
> an input of the device and recorded the audio in which I then visually
> counted samples to verified what I was seeing on the oscilloscope. Also
> running that input through the baudline spectrum analyzer it is easy to see
> the glitches reliably every ~240ms.
> 
> I verified that capture is not affected - I only see the missing sample on
> playback.
> 
> I tested on another computer and the effect was also there, but the interval
> between dropped frames was 100ms longer (~340ms) than on the first computer.

Thanks for the great investigation. Roughly calculation, 240msec for
96.0 kHz equals to 1,920 isoc cycles and 480msec for 48.0 kHz equalds to
3,840 isoc cycles. I need a bit time to consider about the mechanism
(it's blackbox to me).

By the way, in my opinion, ALSA IEC 61883-1/6 packet streaming engine is
need to be enhanced to run according to the effective sampling rate
instead of the ideal one for playback direction if capture direction is
available.

For your information, specification for basic protocol of the packet
streaming is public and available in 1394TA website[5]. In clause
'7.3 Time stamp processing' of the specification, we can see "If a
function block receives a CIP, processes it and subsequently
re-transmits it, then the SYT of the outgoing CIP shall be the sum of
the incoming SYT and the processing delay."

Although the protocol is designed to transfer event data with presentation
timestamp, Tascam FireWire series doesn't use the timestamp synchronization
as well as Fireworks, Digi00x, Fireface. In the cases, I think the sequence
of data blocks per packet is important to synchronization too.

(I note that in a case of USB Audio, the similar way to synchronize
device and host driver is described as 'asynchronous' audio synchronous
type, in clause '3.11.4.3 SOURCE AND SINK ENDPOINTS' of
'USB Audio Device Class Rev.3.0'[6]. The description is easier to
understand.)

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf
[2] https://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git
[3] https://github.com/cladisch/linux-firewire-utils
[4] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/tree/sound/firewire/amdtp-stream.c
[5] Audio and Music Data Transmission Protocol 2.2 Revision 1.1
    http://1394ta.org/wp-content/uploads/2015/07/2009013.pdf
[6] Let you search 'USB Audio Devices Rev. 3.0 and Adopters Agreement' in
    document library in usb.org.
    https://usb.org/documents


Regards

Takashi Sakamoto