Multichannel pcm #1166
Closed
Multichannel pcm #1166
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 8 commits
October 13, 2015 15:46
Allow everything the videocore accepts.
This is required at least for SPDIF. If the bitrate goes above, videocore will either resample the audio or corrupt it due to underruns. Supposedly the hardware isn't designed to output higher rates, but it can still resample it down to supported rates. Some code is based on ac97_pcm.c.
It's messy and I hope it can be removed again in the future. Will be needed for setting the HDMI channel map.
Report all layouts supported by the HDMI protocol to userspace. Make the videocore set the correct layout according to the userspace request. Some code taken from patch_hdmi.c. In particular, the HDMI channel layout table was copied without changes - with the idea in mind that hopefully it can be shared one day. Or at least updating it will be simpler. In my tests, everything appears to work, except when outputting FL FR RL RR. Then my receiver outputs RL on both the RL and RR speakers, while RR is never heard.
I don't think the ALSA framework provides any kind of automatic synchronization within the control callbacks. We most likely need to ensure this manually, so add locking around all access to shared mutable data. In particular, bcm2835_audio_set_ctls() should probably always be called under our own audio lock.
Pad the unused channels with NA. This means userspace needs to write additional, silent padding channels, which is not ideal, but better than noise. Works around noise at the following channel counts: 3, 5, 6, 7
Sending more than 2 channels to videocore while outputting to analogue mysteriously outputs heavy artifacts. So just paint it over with a hack: if analogue is explicitly selected as destination, do not reporting support for anything other than stereo. I'm not sure how to deal with the auto case (destination 0). There's probably way to retrieve this and even to listen to plug events, but I didn't find one yet, and it's probably not worth the trouble. Just don't use this setting, I guess. Unless you like noise. Changing the setting while an audio stream is active also doesn't work properly. We could probably interrupt running streams by returning ENODEV or using kernel hotplug stuff (maybe), but that also doesn't seem worth the trouble.
It appears the GPU only sends us a message all 10ms to update the playback progress. Other than this, the playback position (what SNDRV_PCM_IOCTL_DELAY will return) is not updated at all. Userspace will see jitter up to 10ms in the audio position. Make this a bit nicer for userspace by interpolating the position using the CPU clock. I'm not sure if setting snd_pcm_runtime.delay is the right approach for this. Or if there is maybe an already existing mechanism for position interpolation in the ALSA core. I only set SNDRV_PCM_INFO_BATCH because this appears to remove at least one situation snd_pcm_runtime.delay is used, so I have to worry less in which place I have to update this field, or how it interacts with the rest of ALSA.
This was referenced Oct 13, 2015
Closed
|
I'd like to get this in, but hopefully remove a few of the uglier bits. It bumps the audioserv version to 3. As long as kernel reports 3 it will apply channelmap from VC_AUDIO_CONFIG_T. channelmap is ignored is kernel reports version of 2. As the extra parameter doesn't change the union size, it shouldn't break anything. Can you remove the gencmd and try using the new scheme for setting channelmap. I'd also like to make firmware handle non-power-of-two number of channels. |
popcornmix
added a commit
to raspberrypi/firmware
that referenced
this pull request
Oct 28, 2015
kernel: Add ft6236 touchscreen driver (FT6x06 and FT6x36) See: raspberrypi/linux#1176 firmware: hdmi: flush current pixel clock adjustment on hdmi pixel clock change See: http://forum.kodi.tv/showthread.php?tid=231092&pid=2118254#pid2118254 firmware: memtest: Return info on which data/address bit failed firmware: audioserv: Bump peer version and allow setting of channelmap See: raspberrypi/linux#1166
popcornmix
added a commit
to Hexxeh/rpi-firmware
that referenced
this pull request
Oct 28, 2015
kernel: Add ft6236 touchscreen driver (FT6x06 and FT6x36) See: raspberrypi/linux#1176 firmware: hdmi: flush current pixel clock adjustment on hdmi pixel clock change See: http://forum.kodi.tv/showthread.php?tid=231092&pid=2118254#pid2118254 firmware: memtest: Return info on which data/address bit failed firmware: audioserv: Bump peer version and allow setting of channelmap See: raspberrypi/linux#1166
Yes, I'll try to get to it soon.
In audioserv version 3? |
Not in yet. It can probably be added to version 3 as I doubt anyone other us will be relying on features form version 3 in the next week or so. |
ghost
mentioned this pull request
Closed
|
Replaced with #1257. (Not going to rely on github to pick the correct base, so I opened a new PR.) |
ghost
closed this
popcornmix
pushed a commit
that referenced
this pull request
Jan 19, 2016
Add audioserv 3 extensions. The changes were taken from the paste linked here: #1166 (comment)
popcornmix
pushed a commit
that referenced
this pull request
Feb 1, 2016
Add audioserv 3 extensions. The changes were taken from the paste linked here: #1166 (comment)
popcornmix
pushed a commit
that referenced
this pull request
Feb 18, 2016
Add audioserv 3 extensions. The changes were taken from the paste linked here: #1166 (comment)
popcornmix
pushed a commit
that referenced
this pull request
Feb 26, 2016
Add audioserv 3 extensions. The changes were taken from the paste linked here: #1166 (comment)
popcornmix
pushed a commit
that referenced
this pull request
Mar 4, 2016
Add audioserv 3 extensions. The changes were taken from the paste linked here: #1166 (comment)
popcornmix
pushed a commit
that referenced
this pull request
Mar 10, 2016
Add audioserv 3 extensions. The changes were taken from the paste linked here: #1166 (comment)
popcornmix
pushed a commit
that referenced
this pull request
Mar 10, 2016
Add audioserv 3 extensions. The changes were taken from the paste linked here: #1166 (comment)
popcornmix
pushed a commit
that referenced
this pull request
Mar 16, 2016
Add audioserv 3 extensions. The changes were taken from the paste linked here: #1166 (comment)
pelwell
pushed a commit
that referenced
this pull request
Mar 17, 2016
bcm2835: extend allowed range of channels and samplerates Allow everything the videocore accepts. bcm2835: restrict channels*rate to 8*960000 This is required at least for SPDIF. If the bitrate goes above, videocore will either resample the audio or corrupt it due to underruns. Supposedly the hardware isn't designed to output higher rates, but it can still resample it down to supported rates. Some code is based on ac97_pcm.c. rpi: update vc_vchi_audioserv_defs.h Add audioserv 3 extensions. The changes were taken from the paste linked here: #1166 (comment) bcm2835: implement channel map API Report all layouts supported by the HDMI protocol to userspace. Make the videocore set the correct layout according to the userspace request. Some code taken from patch_hdmi.c. In particular, the HDMI channel layout table was copied without changes - with the idea in mind that hopefully it can be shared one day. Or at least updating it will be simpler. In my tests, everything appears to work, except when outputting FL FR RL RR. Then my receiver outputs RL on both the RL and RR speakers, while RR is never heard. bcm2835: access controls under the audio mutex I don't think the ALSA framework provides any kind of automatic synchronization within the control callbacks. We most likely need to ensure this manually, so add locking around all access to shared mutable data. In particular, bcm2835_audio_set_ctls() should probably always be called under our own audio lock. bcm2835: always use 2/4/8 channels for multichannel layouts Pad the unused channels with NA. This means userspace needs to write additional, silent padding channels, which is not ideal, but better than noise. Works around noise at the following channel counts: 3, 5, 6, 7 bcm2835: only allow stereo if analogue jack is selected Sending more than 2 channels to videocore while outputting to analogue mysteriously outputs heavy artifacts. So just paint it over with a hack: if analogue is explicitly selected as destination, do not reporting support for anything other than stereo. I'm not sure how to deal with the auto case (destination 0). There's probably way to retrieve this and even to listen to plug events, but I didn't find one yet, and it's probably not worth the trouble. Just don't use this setting, I guess. Unless you like noise. Changing the setting while an audio stream is active also doesn't work properly. We could probably interrupt running streams by returning ENODEV or using kernel hotplug stuff (maybe), but that also doesn't seem worth the trouble. bcm2835: interpolate audio delay It appears the GPU only sends us a message all 10ms to update the playback progress. Other than this, the playback position (what SNDRV_PCM_IOCTL_DELAY will return) is not updated at all. Userspace will see jitter up to 10ms in the audio position. Make this a bit nicer for userspace by interpolating the position using the CPU clock. I'm not sure if setting snd_pcm_runtime.delay is the right approach for this. Or if there is maybe an already existing mechanism for position interpolation in the ALSA core. I only set SNDRV_PCM_INFO_BATCH because this appears to remove at least one situation snd_pcm_runtime.delay is used, so I have to worry less in which place I have to update this field, or how it interacts with the rest of ALSA. In the future, it might be nice to use VC_AUDIO_MSG_TYPE_LATENCY. One problem is that it requires sending a videocore message, and waiting for a reply, which could make the implementation much harder due to locking and synchronization requirements.
popcornmix
pushed a commit
that referenced
this pull request
Mar 30, 2016
bcm2835: extend allowed range of channels and samplerates Allow everything the videocore accepts. bcm2835: restrict channels*rate to 8*960000 This is required at least for SPDIF. If the bitrate goes above, videocore will either resample the audio or corrupt it due to underruns. Supposedly the hardware isn't designed to output higher rates, but it can still resample it down to supported rates. Some code is based on ac97_pcm.c. rpi: update vc_vchi_audioserv_defs.h Add audioserv 3 extensions. The changes were taken from the paste linked here: #1166 (comment) bcm2835: implement channel map API Report all layouts supported by the HDMI protocol to userspace. Make the videocore set the correct layout according to the userspace request. Some code taken from patch_hdmi.c. In particular, the HDMI channel layout table was copied without changes - with the idea in mind that hopefully it can be shared one day. Or at least updating it will be simpler. In my tests, everything appears to work, except when outputting FL FR RL RR. Then my receiver outputs RL on both the RL and RR speakers, while RR is never heard. bcm2835: access controls under the audio mutex I don't think the ALSA framework provides any kind of automatic synchronization within the control callbacks. We most likely need to ensure this manually, so add locking around all access to shared mutable data. In particular, bcm2835_audio_set_ctls() should probably always be called under our own audio lock. bcm2835: always use 2/4/8 channels for multichannel layouts Pad the unused channels with NA. This means userspace needs to write additional, silent padding channels, which is not ideal, but better than noise. Works around noise at the following channel counts: 3, 5, 6, 7 bcm2835: only allow stereo if analogue jack is selected Sending more than 2 channels to videocore while outputting to analogue mysteriously outputs heavy artifacts. So just paint it over with a hack: if analogue is explicitly selected as destination, do not reporting support for anything other than stereo. I'm not sure how to deal with the auto case (destination 0). There's probably way to retrieve this and even to listen to plug events, but I didn't find one yet, and it's probably not worth the trouble. Just don't use this setting, I guess. Unless you like noise. Changing the setting while an audio stream is active also doesn't work properly. We could probably interrupt running streams by returning ENODEV or using kernel hotplug stuff (maybe), but that also doesn't seem worth the trouble. bcm2835: interpolate audio delay It appears the GPU only sends us a message all 10ms to update the playback progress. Other than this, the playback position (what SNDRV_PCM_IOCTL_DELAY will return) is not updated at all. Userspace will see jitter up to 10ms in the audio position. Make this a bit nicer for userspace by interpolating the position using the CPU clock. I'm not sure if setting snd_pcm_runtime.delay is the right approach for this. Or if there is maybe an already existing mechanism for position interpolation in the ALSA core. I only set SNDRV_PCM_INFO_BATCH because this appears to remove at least one situation snd_pcm_runtime.delay is used, so I have to worry less in which place I have to update this field, or how it interacts with the rest of ALSA. In the future, it might be nice to use VC_AUDIO_MSG_TYPE_LATENCY. One problem is that it requires sending a videocore message, and waiting for a reply, which could make the implementation much harder due to locking and synchronization requirements.
popcornmix
pushed a commit
that referenced
this pull request
Apr 11, 2016
bcm2835: extend allowed range of channels and samplerates Allow everything the videocore accepts. bcm2835: restrict channels*rate to 8*960000 This is required at least for SPDIF. If the bitrate goes above, videocore will either resample the audio or corrupt it due to underruns. Supposedly the hardware isn't designed to output higher rates, but it can still resample it down to supported rates. Some code is based on ac97_pcm.c. rpi: update vc_vchi_audioserv_defs.h Add audioserv 3 extensions. The changes were taken from the paste linked here: #1166 (comment) bcm2835: implement channel map API Report all layouts supported by the HDMI protocol to userspace. Make the videocore set the correct layout according to the userspace request. Some code taken from patch_hdmi.c. In particular, the HDMI channel layout table was copied without changes - with the idea in mind that hopefully it can be shared one day. Or at least updating it will be simpler. In my tests, everything appears to work, except when outputting FL FR RL RR. Then my receiver outputs RL on both the RL and RR speakers, while RR is never heard. bcm2835: access controls under the audio mutex I don't think the ALSA framework provides any kind of automatic synchronization within the control callbacks. We most likely need to ensure this manually, so add locking around all access to shared mutable data. In particular, bcm2835_audio_set_ctls() should probably always be called under our own audio lock. bcm2835: always use 2/4/8 channels for multichannel layouts Pad the unused channels with NA. This means userspace needs to write additional, silent padding channels, which is not ideal, but better than noise. Works around noise at the following channel counts: 3, 5, 6, 7 bcm2835: only allow stereo if analogue jack is selected Sending more than 2 channels to videocore while outputting to analogue mysteriously outputs heavy artifacts. So just paint it over with a hack: if analogue is explicitly selected as destination, do not reporting support for anything other than stereo. I'm not sure how to deal with the auto case (destination 0). There's probably way to retrieve this and even to listen to plug events, but I didn't find one yet, and it's probably not worth the trouble. Just don't use this setting, I guess. Unless you like noise. Changing the setting while an audio stream is active also doesn't work properly. We could probably interrupt running streams by returning ENODEV or using kernel hotplug stuff (maybe), but that also doesn't seem worth the trouble. bcm2835: interpolate audio delay It appears the GPU only sends us a message all 10ms to update the playback progress. Other than this, the playback position (what SNDRV_PCM_IOCTL_DELAY will return) is not updated at all. Userspace will see jitter up to 10ms in the audio position. Make this a bit nicer for userspace by interpolating the position using the CPU clock. I'm not sure if setting snd_pcm_runtime.delay is the right approach for this. Or if there is maybe an already existing mechanism for position interpolation in the ALSA core. I only set SNDRV_PCM_INFO_BATCH because this appears to remove at least one situation snd_pcm_runtime.delay is used, so I have to worry less in which place I have to update this field, or how it interacts with the rest of ALSA. In the future, it might be nice to use VC_AUDIO_MSG_TYPE_LATENCY. One problem is that it requires sending a videocore message, and waiting for a reply, which could make the implementation much harder due to locking and synchronization requirements.
popcornmix
pushed a commit
that referenced
this pull request
Jun 8, 2016
bcm2835: extend allowed range of channels and samplerates Allow everything the videocore accepts. bcm2835: restrict channels*rate to 8*960000 This is required at least for SPDIF. If the bitrate goes above, videocore will either resample the audio or corrupt it due to underruns. Supposedly the hardware isn't designed to output higher rates, but it can still resample it down to supported rates. Some code is based on ac97_pcm.c. rpi: update vc_vchi_audioserv_defs.h Add audioserv 3 extensions. The changes were taken from the paste linked here: #1166 (comment) bcm2835: implement channel map API Report all layouts supported by the HDMI protocol to userspace. Make the videocore set the correct layout according to the userspace request. Some code taken from patch_hdmi.c. In particular, the HDMI channel layout table was copied without changes - with the idea in mind that hopefully it can be shared one day. Or at least updating it will be simpler. In my tests, everything appears to work, except when outputting FL FR RL RR. Then my receiver outputs RL on both the RL and RR speakers, while RR is never heard. bcm2835: access controls under the audio mutex I don't think the ALSA framework provides any kind of automatic synchronization within the control callbacks. We most likely need to ensure this manually, so add locking around all access to shared mutable data. In particular, bcm2835_audio_set_ctls() should probably always be called under our own audio lock. bcm2835: always use 2/4/8 channels for multichannel layouts Pad the unused channels with NA. This means userspace needs to write additional, silent padding channels, which is not ideal, but better than noise. Works around noise at the following channel counts: 3, 5, 6, 7 bcm2835: only allow stereo if analogue jack is selected Sending more than 2 channels to videocore while outputting to analogue mysteriously outputs heavy artifacts. So just paint it over with a hack: if analogue is explicitly selected as destination, do not reporting support for anything other than stereo. I'm not sure how to deal with the auto case (destination 0). There's probably way to retrieve this and even to listen to plug events, but I didn't find one yet, and it's probably not worth the trouble. Just don't use this setting, I guess. Unless you like noise. Changing the setting while an audio stream is active also doesn't work properly. We could probably interrupt running streams by returning ENODEV or using kernel hotplug stuff (maybe), but that also doesn't seem worth the trouble. bcm2835: interpolate audio delay It appears the GPU only sends us a message all 10ms to update the playback progress. Other than this, the playback position (what SNDRV_PCM_IOCTL_DELAY will return) is not updated at all. Userspace will see jitter up to 10ms in the audio position. Make this a bit nicer for userspace by interpolating the position using the CPU clock. I'm not sure if setting snd_pcm_runtime.delay is the right approach for this. Or if there is maybe an already existing mechanism for position interpolation in the ALSA core. I only set SNDRV_PCM_INFO_BATCH because this appears to remove at least one situation snd_pcm_runtime.delay is used, so I have to worry less in which place I have to update this field, or how it interacts with the rest of ALSA. In the future, it might be nice to use VC_AUDIO_MSG_TYPE_LATENCY. One problem is that it requires sending a videocore message, and waiting for a reply, which could make the implementation much harder due to locking and synchronization requirements.
popcornmix
pushed a commit
that referenced
this pull request
Jun 21, 2016
Add audioserv 3 extensions. The changes were taken from the paste linked here: #1166 (comment)
popcornmix
pushed a commit
that referenced
this pull request
Jun 26, 2016
Add audioserv 3 extensions. The changes were taken from the paste linked here: #1166 (comment)
pma1
pushed a commit
to pma1/ubuntu-xenial
that referenced
this pull request
Jul 31, 2016
Add audioserv 3 extensions. The changes were taken from the paste linked here: raspberrypi/linux#1166 (comment)
bluegray
pushed a commit
to bluegray/ubuntu-xenial
that referenced
this pull request
Sep 25, 2016
Add audioserv 3 extensions. The changes were taken from the paste linked here: raspberrypi/linux#1166 (comment)
ColinIanKing
pushed a commit
to ColinIanKing/ubuntu-xenial
that referenced
this pull request
Oct 28, 2016
Add audioserv 3 extensions. The changes were taken from the paste linked here: raspberrypi/linux#1166 (comment)
angyalp
pushed a commit
to angyalp/kernel_rpi
that referenced
this pull request
Dec 19, 2016
Add audioserv 3 extensions. The changes were taken from the paste linked here: raspberrypi#1166 (comment)
tabp0le
pushed a commit
to tabp0le/ubuntu_xenial_kernel
that referenced
this pull request
Dec 22, 2016
Add audioserv 3 extensions. The changes were taken from the paste linked here: raspberrypi/linux#1166 (comment)
perfecto-devops
pushed a commit
to perfecto-devops/ubuntu-xenial
that referenced
this pull request
Feb 2, 2017
Add audioserv 3 extensions. The changes were taken from the paste linked here: raspberrypi/linux#1166 (comment)
Noltari
pushed a commit
to Noltari/linux
that referenced
this pull request
Feb 6, 2017
Add audioserv 3 extensions. The changes were taken from the paste linked here: raspberrypi/linux#1166 (comment)
neuschaefer
pushed a commit
to neuschaefer/raspi-binary-firmware
that referenced
this pull request
Feb 27, 2017
kernel: Add ft6236 touchscreen driver (FT6x06 and FT6x36) See: raspberrypi/linux#1176 firmware: hdmi: flush current pixel clock adjustment on hdmi pixel clock change See: http://forum.kodi.tv/showthread.php?tid=231092&pid=2118254#pid2118254 firmware: memtest: Return info on which data/address bit failed firmware: audioserv: Bump peer version and allow setting of channelmap See: raspberrypi/linux#1166
JackieLiu1
pushed a commit
to JackieLiu1/kernel
that referenced
this pull request
Mar 23, 2017
Add audioserv 3 extensions. The changes were taken from the paste linked here: raspberrypi/linux#1166 (comment)
woshihuangzhijie
pushed a commit
to woshihuangzhijie/linuxcode
that referenced
this pull request
Sep 20, 2017
Add audioserv 3 extensions. The changes were taken from the paste linked here: raspberrypi/linux#1166 (comment)
amichelotti
pushed a commit
to amichelotti/ubuntu-vme-xenial
that referenced
this pull request
Oct 19, 2017
Add audioserv 3 extensions. The changes were taken from the paste linked here: raspberrypi/linux#1166 (comment)
lianhaidong
pushed a commit
to lianhaidong/ubuntu-xenial
that referenced
this pull request
Nov 6, 2017
Add audioserv 3 extensions. The changes were taken from the paste linked here: raspberrypi/linux#1166 (comment)
liuqun
pushed a commit
to liuqun/linux-raspi2
that referenced
this pull request
Dec 14, 2017
Add audioserv 3 extensions. The changes were taken from the paste linked here: raspberrypi/linux#1166 (comment)
liuqun
pushed a commit
to liuqun/linux-raspi2
that referenced
this pull request
Dec 20, 2017
Add audioserv 3 extensions. The changes were taken from the paste linked here: raspberrypi/linux#1166 (comment)
liuqun
pushed a commit
to liuqun/linux-raspi2
that referenced
this pull request
Dec 20, 2017
Add audioserv 3 extensions. The changes were taken from the paste linked here: raspberrypi/linux#1166 (comment)
liuqun
pushed a commit
to liuqun/linux-raspi2
that referenced
this pull request
Dec 20, 2017
Add audioserv 3 extensions. The changes were taken from the paste linked here: raspberrypi/linux#1166 (comment)
polceanum
pushed a commit
to polceanum/ubuntu-xenial
that referenced
this pull request
Feb 6, 2018
Add audioserv 3 extensions. The changes were taken from the paste linked here: raspberrypi/linux#1166 (comment)
APokorny
pushed a commit
to ubports/ubuntu_kernel_xenial
that referenced
this pull request
Oct 11, 2018
Add audioserv 3 extensions. The changes were taken from the paste linked here: raspberrypi/linux#1166 (comment)
hisenyiu2015
pushed a commit
to hisenyiu2015/msm-4.14
that referenced
this pull request
May 20, 2021
Add audioserv 3 extensions. The changes were taken from the paste linked here: raspberrypi/linux#1166 (comment)
This pull request was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This raises the number of channels to 8, and adds support for the ALSA channel mapping API.
It also includes some other changes, which are strictly speaking not related (see commit list).