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! -- Henrik Austad
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
