Hi Raymond, > How accurate are the hwptr playback/capture position ? It's enough accurate. ...But the position don't show the position in DMA buffer for 'actual hardware'. Let me describe later. > SNDRV_PCM_INFO_BATCH mean hwptr only update in period boundary This flag is appropriate. snd_pcm_period_elapsed() is called when 'hwptr' cross boundary of period. See: in 'amdtp.c' handle_out_packet()/handle_in_packet() ->update_pcm_pointers() ->tasklet_hi_schedule() - pcm_period_tasklet() ->snd_pcm_period_elapsed() > Why period min =1 if it need double buffering ? The drivers don't use 'double buffering'. ...But I don't understand correctly what you said 'double buffering' in this context. So here, let me describe how the drivers use buffer. In brief: [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. [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'. The functionality to packetize is on 'snd-firewire-lib'. Please see 'amdtp.c' in detail. Please inform me if I cannot clear your concern. > The best choice should be jackd instead of pulseaudio > If the hardware must use 10 or more channels and used > for studio production Yes. I think so. But let me describe two points. 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(). 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. Thanks Takashi Sakamoto
