Re: [alsa-devel] [External] Re: alsa-lib: Add ucm support for whiskeylake sof-skl_hda_card audio
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.
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/f796f0852a097e238fa9f5e...
Pierre, could you confirm the original source and are you ok with that?
Thank you, Jaroslav
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/f796f0852a097e238fa9f5efb174e95b5ee6c8b7
Pierre, could you confirm the original source and are you ok with that?
I got confirmation from Intel that they are the original source - they provided me with the files (as an aside in case it is important, originally they were working with Canonical on getting Ubuntu working on one of our (Lenovo) platforms). I was following up with Canonical to just check what they had done but haven't heard back yet.
Since Intel has provided the files to me directly - can I act as an original source confirmation?
So far, the alsa-lib still depends on the card->name/long-name to find the needed UCM, I know some Dell machines also uses sof driver (so the card->name/long-name is also sof-skl_hda_card), so if this UCM is merged, it will be shared with Dell machines. But on those Dell machines, there is no BASS Speaker, and Dell machines have sth that Lenovo machines don't have, like headset-mic and headphone-mic. How to make this UCM work on both Lenovo and Dell machines?
Regards,
Hui.
On 2019/9/24 下午8:06, Mark Pearson wrote:
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/f796f0852a097e238fa9f5efb174e95b5ee6c8b7
Pierre, could you confirm the original source and are you ok with that?
I got confirmation from Intel that they are the original source - they provided me with the files (as an aside in case it is important, originally they were working with Canonical on getting Ubuntu working on one of our (Lenovo) platforms). I was following up with Canonical to just check what they had done but haven't heard back yet.
Since Intel has provided the files to me directly - can I act as an original source confirmation?
Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Dne 27. 09. 19 v 10:21 Hui Wang napsal(a):
So far, the alsa-lib still depends on the card->name/long-name to find the needed UCM, I know some Dell machines also uses sof driver (so the card->name/long-name is also sof-skl_hda_card), so if this UCM is merged, it will be shared with Dell machines. But on those Dell machines, there is no BASS Speaker, and Dell machines have sth that Lenovo machines don't have, like headset-mic and headphone-mic. How to make this UCM work on both Lenovo and Dell machines?
Thanks for this info. The long-name contains DMI info, so I updated the configuration in this way:
https://github.com/alsa-project/alsa-ucm-conf/commit/ac8319245e1213e46a1ae5c...
https://github.com/alsa-project/alsa-ucm-conf/commit/9bd0bf34a571a4a3c38d740...
(everything is in the updated 'import' branch)
So you can add the specific config for the Dell device, too.
Jaroslav
Regards,
Hui.
On 2019/9/24 下午8:06, Mark Pearson wrote:
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/f796f0852a097e238fa9f5efb174e95b5ee6c8b7
Pierre, could you confirm the original source and are you ok with that?
I got confirmation from Intel that they are the original source - they provided me with the files (as an aside in case it is important, originally they were working with Canonical on getting Ubuntu working on one of our (Lenovo) platforms). I was following up with Canonical to just check what they had done but haven't heard back yet.
Since Intel has provided the files to me directly - can I act as an original source confirmation?
Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On 2019/9/27 下午5:01, Jaroslav Kysela wrote:
Dne 27. 09. 19 v 10:21 Hui Wang napsal(a):
So far, the alsa-lib still depends on the card->name/long-name to find the needed UCM, I know some Dell machines also uses sof driver (so the card->name/long-name is also sof-skl_hda_card), so if this UCM is merged, it will be shared with Dell machines. But on those Dell machines, there is no BASS Speaker, and Dell machines have sth that Lenovo machines don't have, like headset-mic and headphone-mic. How to make this UCM work on both Lenovo and Dell machines?
Thanks for this info. The long-name contains DMI info, so I updated the configuration in this way:
https://github.com/alsa-project/alsa-ucm-conf/commit/ac8319245e1213e46a1ae5c...
https://github.com/alsa-project/alsa-ucm-conf/commit/9bd0bf34a571a4a3c38d740...
(everything is in the updated 'import' branch)
So you can add the specific config for the Dell device, too.
OK, that is good, thanks.
Regards,
Hui.
JaroslavRegards,
Hui.
On 2019/9/24 下午8:06, Mark Pearson wrote:
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/f796f0852a097e238fa9f5efb174e95b5ee6c8b7
Pierre, could you confirm the original source and are you ok with that?
I got confirmation from Intel that they are the original source - they provided me with the files (as an aside in case it is important, originally they were working with Canonical on getting Ubuntu working on one of our (Lenovo) platforms). I was following up with Canonical to just check what they had done but haven't heard back yet.
Since Intel has provided the files to me directly - can I act as an original source confirmation?
Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On 2019/9/28 上午11:33, Hui Wang wrote:
On 2019/9/27 下午5:01, Jaroslav Kysela wrote:
Dne 27. 09. 19 v 10:21 Hui Wang napsal(a):
So far, the alsa-lib still depends on the card->name/long-name to find the needed UCM, I know some Dell machines also uses sof driver (so the card->name/long-name is also sof-skl_hda_card), so if this UCM is merged, it will be shared with Dell machines. But on those Dell machines, there is no BASS Speaker, and Dell machines have sth that Lenovo machines don't have, like headset-mic and headphone-mic. How to make this UCM work on both Lenovo and Dell machines?
Thanks for this info. The long-name contains DMI info, so I updated the configuration in this way:
Hello Jaroslav,
For the long->name with DMI info, is it a new feature or an old feature that existing for a long time? If it is a new feature, is it implemented by kernel driver or by alsa-lib, already upstreamed?
Thanks,
Hui.
https://github.com/alsa-project/alsa-ucm-conf/commit/ac8319245e1213e46a1ae5c...
https://github.com/alsa-project/alsa-ucm-conf/commit/9bd0bf34a571a4a3c38d740...
(everything is in the updated 'import' branch)
So you can add the specific config for the Dell device, too.
OK, that is good, thanks.
Regards,
Hui.
Jaroslav
Regards,
Hui.
On 2019/9/24 下午8:06, Mark Pearson wrote:
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/f796f0852a097e238fa9f5efb174e95b5ee6c8b7
Pierre, could you confirm the original source and are you ok with that?
I got confirmation from Intel that they are the original source - they provided me with the files (as an aside in case it is important, originally they were working with Canonical on getting Ubuntu working on one of our (Lenovo) platforms). I was following up with Canonical to just check what they had done but haven't heard back yet.
Since Intel has provided the files to me directly - can I act as an original source confirmation?
Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
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/f796f0852a097e23 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?
br, Jaska
Thank you, Jaroslav
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/f796f0852a097e23 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
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
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.
br, Jaska
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, JaroslavI 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?
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 :-(
Jaroslav
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, JaroslavI 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@perex.cz Linux Sound Maintainer; ALSA Project; Red Hat, Inc. _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
participants (5)
-
Hui Wang -
Jaroslav Kysela -
Jaska Uimonen -
Mark Pearson -
Pierre-Louis Bossart