<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014/1/21 Takashi Sakamoto <span dir="ltr"><<a href="mailto:o-takashi@sakamocchi.jp" target="_blank">o-takashi@sakamocchi.jp</a>></span><br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Raymond,<br> <br> > How accurate are the hwptr playback/capture position ?<br> <br> It's enough accurate.<br></blockquote><div><br></div><div>e,g, USB audio send in URB packet <br><br></div><div>the position is only updated in one ms <br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> ...But the position don't show the position in DMA buffer for 'actual hardware'. Let me describe later.<br> <br> <br> > SNDRV_PCM_INFO_BATCH mean hwptr only update in period boundary<br> <br> This flag is appropriate.<br></blockquote><div><br>Pulseaudio use snd_pcm_rewind the application ptr and rewrite the data <br> <br>do the firewire driver allow application to cancel some submitted packets and resend ?<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> snd_pcm_period_elapsed() is called when 'hwptr' cross boundary of period.<br> <br> See: in 'amdtp.c'<br> handle_out_packet()/handle_in_<u></u>packet()<br> ->update_pcm_pointers()<br> ->tasklet_hi_schedule() - pcm_period_tasklet()<br> ->snd_pcm_period_elapsed()<br></blockquote><div><br></div><div>Do you mean firewire driver 's pcm_pointer callback does not report playback/capture positon in realtime ?<br><br></div><div>there is alway one packet 's uncertainty <br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> <br> In brief:<br> [PCM playback] The drivers generate IEC 61883-1/6 packets from PCM samples in 'struct snd_pcm_runtime.dma_area'. And the drivers write these packets on DMA buffer for OHCI 1394 host controller.<br> [PCM capture] The drivers handle IEC 61883-1/6 packets on DMA buffer for OHCI 1394 host controller. And the drivers pick up PCM samples, write the samples on 'struct snd_pcm_runtime.dma_area'.<br> <br> The functionality to packetize is on 'snd-firewire-lib'. Please see 'amdtp.c' in detail.<br></blockquote><div> <br></div><div>are the any minimum size of the packet ?<br><div><br></div><div>e.g. usb audio send in urb <br> </div><div><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> <br> > The best choice should be jackd instead of pulseaudio<br> > If the hardware must use 10 or more channels and used<br> > for studio production<br> <br> Yes. I think so. But let me describe two points.<br> <br> Current PulseAudio re-tries to detect the profile when the system probe the devices. This corresponds snd_pcm_open() and snd_pcm_close(). So the drivers handle many open()/close() as long as the devices are connected. This is a waste because the drivers generate a few transactions between hardware when open().<br> </blockquote><div><br></div><div>you can add rule to force pulseaudio ignore all firewire cards similar to thinkpad_acpi<br><br><div class="">+SUBSYSTEMS=="firewire", ENV{PULSE_IGNORE}="1"</div><br><br> <a href="http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/src/modules/alsa/mixer/profile-sets/90-pulseaudio.rules?id=078a39af886ea3bb590595b973343af77c2837fe">http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/src/modules/alsa/mixer/profile-sets/90-pulseaudio.rules?id=078a39af886ea3bb590595b973343af77c2837fe</a><br> </div><div> <br><div class=""> </div><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> And many of the devices which the drivers support have 4 or 6 in/out ports and better for daily use. But PulseAudio don't handle such devices.<br></blockquote><div><br><a href="http://libregraphicsworld.org/blog/entry/the-state-of-firewire-audio-interfaces-support-on-linux">http://libregraphicsworld.org/blog/entry/the-state-of-firewire-audio-interfaces-support-on-linux</a><br> <br></div><div>if the devices have hardware mixer , there is no point to use software mixing <br></div><div><br></div></div></div></div>