[pulseaudio-discuss] 'Failed to find a working profile' for firewire sound devices

[Raymond Yau]

2014/1/21 Takashi Sakamoto <o-takashi at sakamocchi.jp>

> Hi Raymond,
>
> > How accurate are the hwptr playback/capture position ?
>
> It's enough accurate.
>

e,g, USB audio send in URB packet

the position is only updated in one ms


>
> ...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.
>

Pulseaudio use snd_pcm_rewind the application ptr and rewrite the data

do the firewire driver allow application to cancel some submitted packets
and resend ?


>
> 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()
>

Do you mean firewire driver 's pcm_pointer callback does not report
playback/capture positon in realtime ?

there is alway one packet 's uncertainty


>
> 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.
>

are the any minimum size of the packet ?

e.g. usb audio send in urb


>
> > 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().
>

you can add rule to force pulseaudio ignore all firewire cards similar to
thinkpad_acpi

+SUBSYSTEMS=="firewire", ENV{PULSE_IGNORE}="1"


http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/src/modules/alsa/mixer/profile-sets/90-pulseaudio.rules?id=078a39af886ea3bb590595b973343af77c2837fe




> 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.
>

http://libregraphicsworld.org/blog/entry/the-state-of-firewire-audio-interfaces-support-on-linux

if the devices have hardware mixer , there is no point to use software
mixing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20140121/220d4066/attachment.html>