Hi,
On Oct 13 2016 17:44, Jordi Torres wrote:
(CCed to alsa-devel)
I sent this issue to alsa mailist 6 days ago but I supouse that hit the spam filter. Even I published an alsa-info http://www.alsa-project.org/db/?f=cb6745b6d0acdb5d9375096ec8dc008f6ff49cd7
You need to create your account to blast your messages to subscribers.
When I read the wiki about reporting bugs, I understood that kernel related bugs goes to bugzilla.kernel.org and user-land bugs goes to the devel mail-list. So I supouse that I should sent this issue to the bugzilla as it's considered a kernel bug
I don't mind to receive bug reports in this mailing list, instead of bugsilla. Both are OK to me.
Well, could I request you to gather information of packet sequence?
Here is the trace of packets:
https://drive.google.com/file/d/0Bz44Dr5G2FeJSXBHMzc5WTFmOWs/view?usp=sharin...
The trace includes the opening of alsa device and playing a sine wave for 30 seconds
Thanks. I can diagnose incoming packets from your unit according to the log. This is the result:
Isochronous channel 0: Cycle count (sec): packets data-blocks 0: 0 0 4: 64 232.0 5: 16 48.0 7: 32 136.0 1: 16 88.0 6: 16 88.0 0: 16 96.0 2: 80 472.0 5: 5071 30424.0 6: 8000 48008.0 7: 8000 48000.0 0: 8000 48008.0 1: 8000 48000.0 2: 8000 48008.0 3: 8000 48000.0 4: 8000 48000.0 5: 8000 48008.0 6: 8000 48000.0 7: 8000 48008.0 0: 8000 48000.0 1: 8000 48008.0 2: 8000 48000.0 3: 8000 48008.0 4: 8000 48000.0 5: 8000 48008.0 6: 8000 48000.0 7: 8000 48008.0 0: 8000 48000.0 1: 8000 48008.0 2: 8000 48000.0 3: 8000 48008.0 4: 8000 48000.0 5: 8000 48008.0 6: 8000 48000.0 7: 8000 48008.0 0: 8000 48000.0 1: 8000 48008.0 2: 8000 48000.0
Hm, in the beginning of packet streaming, your unit looks to transfer packets intermittently.
In intermediate cycle count at 5 sec, your unit transferred packets periodically. But the total count of data block is not exactly the same as sampling transfer frequency. This means that your unit puts more PCM samples than current sampling rate. One time every 2 second, your unit put additional 8 samples. This quirk is the same as I can see with my ImpactTwin.
In detail of my investigation for the other Dice-based units, please read: [alsa-devel] Dice packet sequence quirk and ALSA firewire stack in Linux 4.6 http://mailman.alsa-project.org/pipermail/alsa-devel/2016-May/107715.html
On the other hand, we can see that packet streaming engine on ALSA firewire stack transfers data blocks at exactly the same as current sampling transfer frequency.
Isochronous channel 1: Cycle count (sec): packets data-blocks 0: 0 0 6: 96 576.0 0: 112 672.0 2: 160 960.0 5: 5057 30344.0 6: 8000 48000.0 7: 8000 48000.0 0: 8000 48000.0 1: 8000 48000.0 2: 8000 48000.0 3: 8000 48000.0 4: 8000 48000.0 5: 8000 48000.0 6: 8000 48000.0 7: 8000 48000.0 0: 8000 48000.0 1: 8000 48000.0 2: 8000 48000.0 3: 8000 48000.0 4: 8000 48000.0 5: 8000 48000.0 6: 8000 48000.0 7: 8000 48000.0 0: 8000 48000.0 1: 8000 48000.0 2: 8000 48000.0 3: 8000 48000.0 4: 8000 48000.0 5: 8000 48000.0 6: 8000 48000.0 7: 8000 48000.0 0: 8000 48000.0 1: 8000 48000.0 2: 8000 48000.0
Isochronous channel 2: Cycle count (sec): packets data-blocks 0: 0 0 6: 80 480.0 0: 80 480.0 2: 144 864.0 5: 5039 30240.0 6: 8000 48000.0 7: 8000 48000.0 0: 8000 48000.0 1: 8000 48000.0 2: 8000 48000.0 3: 8000 48000.0 4: 8000 48000.0 5: 8000 48000.0 6: 8000 48000.0 7: 8000 48000.0 0: 8000 48000.0 1: 8000 48000.0 2: 8000 48000.0 3: 8000 48000.0 4: 8000 48000.0 5: 8000 48000.0 6: 8000 48000.0 7: 8000 48000.0 0: 8000 48000.0 1: 8000 48000.0 2: 8000 48000.0 3: 8000 48000.0 4: 8000 48000.0 5: 8000 48000.0 6: 8000 48000.0 7: 8000 48000.0 0: 8000 48000.0 1: 8000 48000.0 2: 8000 48000.0
In the beginning of both packet streams, we can see cycle jumps. I think this comes from behaviours of Audacity or PortAudio v1.9. The combination starts ALSA PCM substreams several times before continuous PCM substreams.
Well, the mismatch between the number of data blocks per seconds from Dice-based units and from ALSA firewire stack causes the de-sync of device internal processing and generates periodical noise, currently I guess.
My linux box has two firewire ports I don't know the details about the host controller but could be feasible sniff the connection between the other computer with official drivers and the DAW? Could that be useful?
PD: Resent due to using the wrong sender address
Please keep the continuity of 'in-reply-to' header field of messages so that related messages are related to one message thread.
Regards
Takashi Sakamoto