On Fri, Sep 27, 2019 at 04:49:29PM +0200, Jaroslav Kysela wrote: > Dne 27. 09. 19 v 16:00 Jaska Uimonen napsal(a): > > On Fri, 2019-09-27 at 12:57 +0200, Jaroslav Kysela wrote: > >> Dne 27. 09. 19 v 12:07 Jaska Uimonen napsal(a): > >>> On Tue, 2019-09-24 at 13:53 +0200, Jaroslav Kysela wrote: > >>>> Dne 19. 09. 19 v 17:15 Pierre-Louis Bossart napsal(a): > >>>>> On 9/19/19 9:54 AM, Mark Pearson wrote: > >>>>>>> > >>>>>>> Indeed UCM is required for all cases where SOF and > >>>>>>> PulseAudio > >>>>>>> are used. > >>>>>>> > >>>>>>> Our thinking was however to add this UCM file to the new > >>>>>>> repository outside > >>>>>>> of alsa-lib [1]. There is an on-going thread started by > >>>>>>> Jaroslav to move those > >>>>>>> files and relicense them as BSD-3-Clause [2] > >>>>>>> > >>>>>>> [1] > >>>>>>> https://mailman.alsa-project.org/pipermail/alsa-devel/2019- > >>>>>>> July/153257.html > >>>>>>> [2] > >>>>>>> https://mailman.alsa-project.org/pipermail/alsa-devel/2019- > >>>>>>> September/155246.html > >>>>>> > >>>>>> Thanks Pierre. > >>>>>> > >>>>>> Do we have any approximate timelines on when and how this > >>>>>> will > >>>>>> happen? (I'm new to this) > >>>>>> > >>>>>> One of my main aims is that we have a customer using Debian > >>>>>> and > >>>>>> one of our platforms that require this change - I need to > >>>>>> make > >>>>>> sure I understand how this would roll out and what actions > >>>>>> they > >>>>>> need to take in the meantime if it's not going to be > >>>>>> available in > >>>>>> Debian. > >>>>> > >>>>> I think the first order would be to have the file cleaned-up, > >>>>> with > >>>>> its > >>>>> Intel origin clearly stated with a signed-off-by tag. > >>>>> > >>>>> Then once this is done, the Debian package creation needs to be > >>>>> handled > >>>>> (using either the ALSA repo or the cloned version on SOF > >>>>> GitHub). > >>>>> I > >>>>> don't have any experience with Debian packages so can't really > >>>>> comment > >>>>> on the effort it would take. > >>>> > >>>> I did some cleanups here: > >>>> > >>>> https://github.com/alsa-project/alsa-ucm-conf/commit/f796f0852a09 > >>>> 7e23 > >>>> 8fa9f5efb174e95b5ee6c8b7 > >>>> > >>>> Pierre, could you confirm the original source and are you ok with > >>>> that? > >>> > >>> Cleanup looks fine to me, we should add still UCM "PlaybackVolume" > >>> and > >>> "CaptureVolume" settings, because otherwise Pulseaudio will use SW > >>> volume only. This will make for example HDA led quirks useless... > >>> (and actually CaptureVolume and PlaybackVolume in pulseaudio ucm > >>> support is still not integrated, hopefully soon). Defining Capture > >>> and > >>> PlaybackVolume should not do any harm currently for user space. > >>> > >>> I can do that, Jaroslav you want PR against github or patches here > >>> to mailing list? > >> > >> As you wish. Both ways are acceptable for me. Note that I did another > >> cleanup > >> for 'Bass Speaker' for Carbon X1 7th and merged 'import' branch to > >> 'master' > >> branch on github (so do the PR against master, if you like). > >> > >> Thanks, > >> Jaroslav > >> > > > > I made now: > > https://github.com/alsa-project/alsa-ucm-conf/pull/1 > > and > > https://github.com/alsa-project/alsa-ucm-conf/pull/2 > > Thanks. Why switches (PlaybackSwitch/CaptureSwitch) are not defined, too? Currently the pulseaudio patch I'm testing uses only PlaybackVolume and CaptureVolume. However Pulseaudio searches also for related switch control. So if you have combined alsa volume element with switch, both are set in hardware. With PlaybackSwitch we could define switch in separate element to volume, which actually could be useful in some use cases. Most cases however I see the mute switch combined with the volume. So maybe incremental addition when this gets implemented by Pulseaudio? OTH should not do harm either, so in that sense I could add it.. > > > It would be good if Lenovo and Canonical folks also check these. > > > > I'm testing this in Dell device with Ubuntu and twiddling outputs > > and volumes/mutes from UI. PR 2 is assuming Pulseaudio HW control, > > so not sure if the changes bad without it. > > BTW: Could you, Intel guys, review other UCM profiles for the SST drivers, > too? It seems that PlaybackVolume is only in few other profiles and no one is > using switches and capture CTL ID definitions. It basically means, that all > UCM profiles are broken and only software volume is used in PA :-( > I will surely go through all SOF related UCM's and fix/add them to repo. AFAIK most legacy drivers are used without UCM by Pulseaudio in major distros. So not sure how useful this is? To be honest, I think most older UCM's are not really well tested with full audio stack (including Pulseaudio), probably with command line ucm tools only. br, Jaska > Jaroslav > > -- > Jaroslav Kysela <perex@xxxxxxxx> > Linux Sound Maintainer; ALSA Project; Red Hat, Inc. > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@xxxxxxxxxxxxxxxx > https://mailman.alsa-project.org/mailman/listinfo/alsa-devel _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
