On Sun, Jun 12, 2016 at 12:38:36PM +0900, Takashi Sakamoto wrote:
Hi,
I'm one of maintainers for ALSA firewire stack, which handles IEC 61883-1/6 and vendor-unique packets on IEEE 1394 bus for consumer recording equipments. (I'm not in MAINTAINERS because I'm a shy boy.)
IEC 61883-6 describes that one packet can multiplex several types of data in its data channels; i.e. Multi Bit Linear Audio data (PCM samples), One Bit Audio Data (DSD), MIDI messages and so on.
Hmm, that I did not know, not sure how that applies to AVB, but definately something I have to look into.
If you handles packet payload in 'struct snd_pcm_ops.copy', a process context of an ALSA PCM applications performs the work. Thus, no chances to multiplex data with the other types.
Hmm, ok, I didn't know that, that is something I need to look into -and incidentally one of the reasons why I posted the series now instead of a few more months down the road - thanks!
The driver is not adhering fully to any standards right now, the amount of detail is quite high - but I'm slowly improving as I go through the standards. Getting on top of all the standards and all the different subsystems are definately a work in progress (it's a lot to digest!)
To prevent this situation, current ALSA firewire stack handles packet payload in software interrupt context of isochronous context of OHCI 1394. As a result of this, the software stack supports PCM substreams and MIDI substreams.
In your patcset, there's no actual codes about how to handle any interrupt contexts (software / hardware), how to handle packet payload, and so on. Especially, for recent sound subsystem, the timing of generating interrupts and which context does what works are important to reduce playback/capture latency and power consumption.
See reply in other mail :)
Of source, your intention of this patchset is to show your early concept of TSN feature. Nevertheless, both of explaination and codes are important to the other developers who have little knowledges about TSN, AVB and AES-64 such as me.
Yes, that is one of the things I aimed for, and also getting feedback on the overall thinking
And, I might cooperate to prepare for common IEC 61883 layer. For actual codes of ALSA firewire stack, please see mainline kernel code. For actual devices of IEC 61883-1/6 and IEEE 1394 bus, please refer to my report in 2014. At least, you can get to know what to consider about developing upper drivers near ALSA userspace applications. https://github.com/takaswie/alsa-firewire-report
Thanks, I'll dig into that, much appreciated
(But I confirm that the report includes my misunderstandings in clause 3.4 and 6.2. need more time...)
ok, good to know
Thank you for your input, very much appreicated!