Re: [pulseaudio-discuss] ASoC and pulseaudio

[Carlo Caione]

On Sat, Feb 20, 2016 at 7:22 PM, Pierre-Louis Bossart
 wrote:

>> So, what is the suggested way to accomplish this and in general how PA
>> is trying to address this problem? I expect in the future to see many
>> more ASoC coming into the laptops world, how will the community make
>> it so that you install a distro and then sound "just works"?
>
> Not an easy problem. I generated a set of UCM files for baytrail-based 
> platforms and I was planning on doing the same for CHT now that there are a 
> set of commercially available devices.
> There are however a set of limitations that are known already, e.g. the UCM 
> file matches the machine driver name, so if there are any quirks inside the 
> driver we'd need to add a DMI-based info to the card name and also build UCM 
> files based on an include mechanism, otherwise it's going to be copy/paste 
> hell
> Adding Liam to make sure he sees this thread.

Just FYI this is the set of UCM files I'm currently using for CHT:

https://gist.github.com/29503e7c77d3681a51da
https://gist.github.com/1ac67d26b4ddf64c8f28

Cheers,

-- 
Carlo Caione  |  +39.340.80.30.096  |  Endless
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] role-ducking: Fix improper unducking behavior in case of operating globally

[Arun Raghavan]

On Thu, 2016-02-18 at 17:09 +0100, Georg Chini wrote:
> On 18.02.2016 10:40, Arun Raghavan wrote:
> > On Thu, 2016-02-11 at 23:11 +0900, Sangchul Lee wrote:
> > > Fix improper unducking behavior when using this module with
> > > "global=1" argument.
> > > 
> > > BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=93994
> > > 
> > > Signed-off-by: Sangchul Lee 
> > > ---
> > Looks good to me, pushed thanks.
> > 
> > -- Arun
> > ___
> > pulseaudio-discuss mailing list
> > pulseaudio-discuss@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
> Hi Arun,
> 
> there has been a patch series I sent a while ago which combines module 
> role-cork
> and module-role-ducking because they contain lots of duplicated code. 
> This series has
> never been reviewed. Maybe you can take a look at it?
> You can find it at 
> http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/23189

I think this does make sense. The stream selection logic is the same
between the two modules, and it's only what we do after selecting the
stream that changes.

I'll try to get to this after reviewing the RAOP series.

Thank you for your patience.

Regards,
Arun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH v4 05/23] echo-cancel: Relax restrictions on webrtc AEC stream config

[Arun Raghavan]

On Sat, 2016-02-20 at 15:35 +0200, Tanu Kaskinen wrote:
> On Wed, 2016-02-17 at 19:46 +0530, a...@accosted.net wrote:
> > From: Arun Raghavan 
> > 
> > This exposes the range of configurations the library actually supports
> > (8, 16, 32 and 48 kHz).
> 
> That doesn't seem to explain all changes in the code. I'll analyze all
> the variables:
> 
> play_ss.format is handled as before, fixed to s16le.
> 
> play_ss.rate was earlier set to out_ss.rate, now it's set to one of the
> four possible rates based on the initial rec_ss.rate value.
> 
> play_ss.channels and play_map were earlier set to out_map, now they are
> unchanged.
> 
> rec_ss.format is handled as before, fixed to s16le.
> 
> rec_ss.rate was earlier set to out_ss.rate, now it's set to one of the
> four possible rates based on the initial rec_ss.rate value.
> 
> rec_ss.channels and rec_map were earlier set to out_map, now they are
> unchanged.
> 
> out_ss.format is handled as before, fixed to s16le.
> 
> out_ss.rate was earlier kept unchanged, now it's set to one of the four
> possible rates based on the initial rec_ss.rate value.
> 
> out_ss.channels and out_map were earlier kept unchanged, now they are
> set to the original value of rec_map.
> 
> In summary: no changes in sample format configuration, rate is based on
> the original rec_ss instead of the original out_ss and limited to the
> four possible rates (earlier there was no such limitation, so is the
> commit message wrong saying "relax restrictions"?), channels are based
> on rec_map instead of out_map.

Functionally, there is no difference. out_ss/map and rec_ss/map
essentially had the same value, and I just used them interchangeably
(which now IMO is confusing).

In the refactoring, I'm expressing the constraints in what I see to be
a more natural way -- rec_ss expresses what we're feeding the
canceller, so it makes sense to apply the constraints on what the
canceller accepts there. This then propagates to the output spec.

This all seems fairly minor to me, but I can add it to the commit
message as well if you want.

> There is and there was no limitation on the channel count - but should
> there be? I don't think the processing can handle very many channels,
> at least before switching to deinterleaved processing.

The AudioProcessing API doesn't document constraints on the channel
count (I suppose there are constraints internally, though, given what
you'd posted earlier w.r.t. the AudioFrame buffer size). I think fixing
that in this commit would be wasted effort since, as you point out, the
deinterleaved processing does make that irrelevant.

-- Arun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH v6 00/37] raop2 support for module-raop-sink

[Hajime Fujita]

Hi Arun,

> On Feb 15, 2016, at 3:32 AM, Arun Raghavan  wrote:
> 
> On 12 February 2016 at 12:03, Hajime Fujita  wrote:
>> Hi Arun,
>> 
>> Arun Raghavan wrote:
>>> Hi Hajime,
>>> I'm still working on this, it's slow going since I have other things to
>>> do in parallel.
>> 
>> Thank you for your reply. Yeah that's totally fine. Just wanted make sure if 
>> it was appropriate to submit a new series.
>> 
>>> It's a bit hard to review this work properly per-commit, so I'm going
>>> to try to summarise the issues I've found at one go.
>>> 
>>> * There are some style issues that I'm fixing up as I find, and I'll
>>> just have that as a commit on top of your tree.
>>> 
>>> * While testing, I see there are two instances loaded every time (one
>>> for IPv4 and one for IPv6) -- wouldn't it be more user friendly to make
>>> sure we load only one? This doesn't appear to be a new issue, so not a
>>> blocker on this series
>> 
>> I've been aware of this for a while. I think my thought was that some user 
>> might want to explicitly choose IPv4 or v6 address. I'm not sure if it is a 
>> real need though.
>> 
>>> 
>>> * I tried this against Airserver on a Mac (worked) and a current
>>> generation Apple TV (did not work) -- just got stuck trying to start
>>> playback
>> 
>> Hmm you mean the latest Apple TV which came out last year? I currently don't 
>> have that one so it'll be a bit hard to debug... let me check the price :)
> 
> That's the one. I might be able to try again and get you a packet
> capture if that helps.

Yeah that’d definitely help.


Thank you,
Hajime

> 
> -- Arun
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss