On Sun, Jun 12, 2016 at 07:43:34PM +0900, Takashi Sakamoto wrote: > On Jun 12 2016 17:31, Henrik Austad wrote: > > On Sun, Jun 12, 2016 at 01:30:24PM +0900, Takashi Sakamoto wrote: > >> On Jun 12 2016 12:38, Takashi Sakamoto wrote: > >>> 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. > >>> > >>> 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. > >> > >> Oops. Your 5th patch was skipped by alsa-project.org. I guess that size > >> of the patch is too large to the list service. I can see it: > >> http://marc.info/?l=linux-netdev&m=146568672728661&w=2 > >> > >> As long as seeing the patch, packets are queueing in hrtimer callbacks > >> every 1 seconds. > > > > Actually, the hrtimer fires every 1ms, and that part is something I have to > > do something about, also because it sends of the same number of frames > > every time, regardless of how accurate the internal timer is to the rest of > > the network (there's no backpressure from the networking layer). > > > >> (This is a high level discussion and it's OK to ignore it for the > >> moment. When writing packet-oriented drivers for sound subsystem, you > >> need to pay special attention to accuracy of the number of PCM frames > >> transferred currently, and granularity of the number of PCM frames > >> transferred by one operation. In this case, snd_avb_hw, > >> snd_avb_pcm_pointer(), tsn_buffer_write_net() and tsn_buffer_read_net() > >> are involved in this discussion. You can see ALSA developers' struggle > >> in USB audio device class drivers and (of cource) IEC 61883-1/6 drivers.) > > > > Ah, good point. Any particular parts of the USB-subsystem I should start > > looking at? > > I don't think it's a beter way for you to study USB Audio Device Class > driver unless you're interested in ALSA or USB subsystem. > > (But for your information, snd-usb-audio is in sound/usb/* of Linux > kernel. IEC 61883-1/6 driver is in sound/firewire/*.) Ok, thanks, I'll definately be looking at the firewire bit > We need different strategy to achieve it on different transmission backend. > > > Knowing where to start looking is a tremendous help > > It's not well-documented, and not well-generalized for packet-oriented > drivers. Most of developers who have enough knowledge about it work for > DMA-oriented drivers in mobile platforms and have little interests in > packet-oriented drivers. You need to find your own way. > > Currently I have few advices to you, because I'm also on the way for > drivers to process IEC 61883-1/6 packets on IEEE 1394 bus with enough > accuracy and granularity. The paper I introduced is for the way (but not > mature). > > I wish you get more helps from the other developers. Your work is more > significant to Linux system, than mine. > > (And I hope your future work get no ignorance and no unreasonable > hostility from coarse users.) Ah well, I have asbestos-underwear so that should be fine :) Thanks for the pointers, I really appreciate them! -- Henrik Austad
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
