[pulseaudio-discuss] 'Failed to find a working profile' for firewire sound devices
o-takashi at sakamocchi.jp
Mon Jan 20 23:17:20 PST 2014
> 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'
->tasklet_hi_schedule() - pcm_period_tasklet()
> 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.
[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.
More information about the pulseaudio-discuss