Sorry for the repost. I screwed up the subject line.
/ >I'm trying to integrate an ALSA driver I've written for an embedded />/platform with PulseAudio 4.0. The "soundcard" has 32 channels, of which
/>/I'm trying to use 24. The dummy and loopback ALSA devices come up as cards />/0 and 1. My
>I'm trying to integrate an ALSA driver I've written for an embedded
platform with PulseAudio 4.0. The "soundcard" has 32 channels, of which
I'm trying to use 24. The dummy and loopback ALSA devices come up as cards
0 and 1. My device comes up as card 2.
>
>My simple loopback of 2 groups of
On 20.03.2016 19:13, Alexander E. Patrakov wrote:
20.03.2016 22:41, Georg Chini пишет:
Hello,
I am still working on module-loopback and hit a problem that I cannot
explain.
When running a HDA card with long latency (333ms) I see that the
resulting
latency is not stable but varies around 300
20.03.2016 22:41, Georg Chini пишет:
Hello,
I am still working on module-loopback and hit a problem that I cannot
explain.
When running a HDA card with long latency (333ms) I see that the resulting
latency is not stable but varies around 300 usec. What is worse, the
changes
in latency are not
This patch deals with the case that applications start new streams corked.
It was not included in the original series but sent at a later time.
In case of module-role-cork it will only mute the stream because corking is
removed later by the application.
---
src/modules/stream-interaction.c | 32
On Tue, Mar 15, 2016 at 10:58:26AM +, Liam Girdwood wrote:
> On Tue, 2016-03-15 at 10:56 +0100, Takashi Iwai wrote:
> > On Tue, 15 Mar 2016 10:48:51 +0100,
> > Liam Girdwood wrote:
> > >
> > > On Tue, 2016-03-15 at 09:55 +0100, Takashi Iwai wrote:
> > > > On Tue, 15 Mar 2016 09:45:44 +0100,
>
On 18.03.2016 09:15, Tanu Kaskinen wrote:
On Thu, 2016-03-17 at 22:35 +0100, Georg Chini wrote:
+static const char find_global_trigger_stream(struct userdata *u, pa_sink *s,
pa_sink_input *ignore) {
You said you didn't do a "full test", but please at least test that the
code compiles cleanly.
On Wed, Mar 16, 2016 at 08:27:04PM +0530, Vinod Koul wrote:
> So I don't think FW name would help, if required we should add dev_info
> to print the firmware which is getting loaded.
We can't really be relying on userspace trawling through the logs -
quite apart from anything else the message
