Yeah pulseaudio is doing the same on Raspbian with USB devices. Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 From: alsa-devel-request@xxxxxxxxxxxxxxxx<mailto:alsa-devel-request@xxxxxxxxxxxxxxxx> Sent: 09 June 2020 22:40 To: alsa-devel@xxxxxxxxxxxxxxxx<mailto:alsa-devel@xxxxxxxxxxxxxxxx> Subject: Alsa-devel Digest, Vol 160, Issue 72 Send Alsa-devel mailing list submissions to alsa-devel@xxxxxxxxxxxxxxxx To subscribe or unsubscribe via the World Wide Web, visit https://mailman.alsa-project.org/mailman/listinfo/alsa-devel or, via email, send a message with subject or body 'help' to alsa-devel-request@xxxxxxxxxxxxxxxx You can reach the person managing the list at alsa-devel-owner@xxxxxxxxxxxxxxxx When replying, please edit your Subject line so it is more specific than "Re: Contents of Alsa-devel digest..." Today's Topics: 1. Re: [RFC PATCH 0/2] TAS2563 DSP Firmware Loader (Dan Murphy) 2. Re: [RFC PATCH 0/2] TAS2563 DSP Firmware Loader (Mark Brown) 3. Re: [RFC PATCH 1/2] dt-bindings: tas2562: Add firmware support for tas2563 (Mark Brown) 4. Re: [RFC PATCH 1/2] dt-bindings: tas2562: Add firmware support for tas2563 (Dan Murphy) 5. We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail. Jun 09 14:31:33 elrond pulseaudio[11933]: Most likely this is a bug in the ALSA driver 'snd_usb_audio'. Please report this issue to the ALSA developers. Jun 09 14:31:33 elrond pulseaudio[11933]: ALSA woke us up to write new data to the device, but there was actually nothing to write. (GitHub issues - opened) 6. We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail. Jun 09 14:31:33 elrond pulseaudio[11933]: Most likely this is a bug in the ALSA driver 'snd_usb_audio'. Please report this issue to the ALSA developers. Jun 09 14:31:33 elrond pulseaudio[11933]: ALSA woke us up to write new data to the device, but there was actually nothing to write. (GitHub issues - edited) 7. ALSA journalctl error. (GitHub issues - edited) 8. ALSA journalctl Error (GitHub issues - edited) ---------------------------------------------------------------------- Message: 1 Date: Tue, 9 Jun 2020 13:07:50 -0500 From: Dan Murphy <dmurphy@xxxxxx> To: Mark Brown <broonie@xxxxxxxxxx> Cc: robh@xxxxxxxxxx, alsa-devel@xxxxxxxxxxxxxxxx, devicetree@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, tiwai@xxxxxxxx, lgirdwood@xxxxxxxxx Subject: Re: [RFC PATCH 0/2] TAS2563 DSP Firmware Loader Message-ID: <6d6aaed3-dac8-e1ec-436c-9b04273df2b3@xxxxxx> Content-Type: text/plain; charset="windows-1252"; format=flowed Mark On 6/9/20 12:52 PM, Mark Brown wrote: > On Tue, Jun 09, 2020 at 12:28:39PM -0500, Dan Murphy wrote: > >> These programs and configurations are selectable via files under the I2C dev >> node. There may be a better way to select this through ALSA controls but I was >> unable to find a good example of this. This is why this is an RFC patchset. > I think you can just use enums for most of this - what you want to do I > think is parse the firmware, build templates for the controls and then > add them with snd_soc_add_component_controls(). Userspace *should* cope > with controls being hotplugged. Yes this was my concern if userspace could cope with dynamic controls. Dan ------------------------------ Message: 2 Date: Tue, 9 Jun 2020 19:16:15 +0100 From: Mark Brown <broonie@xxxxxxxxxx> To: Dan Murphy <dmurphy@xxxxxx> Cc: robh@xxxxxxxxxx, alsa-devel@xxxxxxxxxxxxxxxx, devicetree@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, tiwai@xxxxxxxx, lgirdwood@xxxxxxxxx Subject: Re: [RFC PATCH 0/2] TAS2563 DSP Firmware Loader Message-ID: <20200609181615.GR4583@xxxxxxxxxxxxx> Content-Type: text/plain; charset="us-ascii" On Tue, Jun 09, 2020 at 01:07:50PM -0500, Dan Murphy wrote: > On 6/9/20 12:52 PM, Mark Brown wrote: > > I think you can just use enums for most of this - what you want to do I > > think is parse the firmware, build templates for the controls and then > > add them with snd_soc_add_component_controls(). Userspace *should* cope > > with controls being hotplugged. > Yes this was my concern if userspace could cope with dynamic controls. Things like alsactl definitely do, and obviously anything that starts after the firmware loads will be fine too. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20200609/0cf2f996/attachment-0001.sig> ------------------------------ Message: 3 Date: Tue, 9 Jun 2020 19:47:34 +0100 From: Mark Brown <broonie@xxxxxxxxxx> To: Dan Murphy <dmurphy@xxxxxx> Cc: robh@xxxxxxxxxx, alsa-devel@xxxxxxxxxxxxxxxx, devicetree@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, tiwai@xxxxxxxx, lgirdwood@xxxxxxxxx Subject: Re: [RFC PATCH 1/2] dt-bindings: tas2562: Add firmware support for tas2563 Message-ID: <20200609184734.GS4583@xxxxxxxxxxxxx> Content-Type: text/plain; charset="iso-8859-1" On Tue, Jun 09, 2020 at 01:06:50PM -0500, Dan Murphy wrote: > I could make a default as you suggested to include i2c address and bus in > the name.? But the TAS2563 does not need the firmware to operate and the > 2562 does not have a DSP. That's fine, the driver can just use the compatible string to check this and not offer any of the DSP related stuff (it should do this regardless of the method used here). I'm guessing the regmap configs should also be different. > What if there was an ALSA control instead that passed in the firmware name > from the user space instead of using the DT? > Then the control can load and parse the firmware and wait for the user to > select the program. > This would solve a user from having ot update the DT to use a firmware. That's really not very idiomatic for how Linux does stuff and seems to pretty much guarantee issues with hotplugging controls and ordering - you'd need special userspace to start up even if it was just a really simple DSP config doing only speaker correction or something. I'm not sure what the advantage would be - what problem is this solving over static names? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20200609/c90c0f22/attachment-0001.sig> ------------------------------ Message: 4 Date: Tue, 9 Jun 2020 14:20:29 -0500 From: Dan Murphy <dmurphy@xxxxxx> To: Mark Brown <broonie@xxxxxxxxxx> Cc: robh@xxxxxxxxxx, alsa-devel@xxxxxxxxxxxxxxxx, devicetree@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, tiwai@xxxxxxxx, lgirdwood@xxxxxxxxx Subject: Re: [RFC PATCH 1/2] dt-bindings: tas2562: Add firmware support for tas2563 Message-ID: <014b85b5-677b-569a-4eb2-74526d3f00bc@xxxxxx> Content-Type: text/plain; charset="windows-1252"; format=flowed Mark On 6/9/20 1:47 PM, Mark Brown wrote: > On Tue, Jun 09, 2020 at 01:06:50PM -0500, Dan Murphy wrote: > >> I could make a default as you suggested to include i2c address and bus in >> the name.? But the TAS2563 does not need the firmware to operate and the >> 2562 does not have a DSP. > That's fine, the driver can just use the compatible string to check this > and not offer any of the DSP related stuff (it should do this regardless > of the method used here). I'm guessing the regmap configs should also > be different. The driver does check the compatible to determine if DSP loading is available for the device. The driver also checks to see if the firmware file is declared in the DT. So it has to pass 2 checks to even load and parse the firmware to present the controls for the programs and configs. >> What if there was an ALSA control instead that passed in the firmware name >> from the user space instead of using the DT? >> Then the control can load and parse the firmware and wait for the user to >> select the program. >> This would solve a user from having ot update the DT to use a firmware. > That's really not very idiomatic for how Linux does stuff and seems to > pretty much guarantee issues with hotplugging controls and ordering - > you'd need special userspace to start up even if it was just a really > simple DSP config doing only speaker correction or something. I'm not > sure what the advantage would be - what problem is this solving over > static names? IMO having a static name is the problem. It is an inflexible design.? Besides the firmware-name property seems to be used in other drivers to declare firmwares for the boards. But if no one is complaining or submitting patches within the codecs to be more flexible with firmware then I can just hard code the name like other drivers do. Dan ------------------------------ Message: 5 Date: Tue, 9 Jun 2020 23:37:09 +0200 (CEST) From: GitHub issues - opened <github@xxxxxxxxxxxxxxxx> To: alsa-devel@xxxxxxxxxxxxxxxx Subject: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail. Jun 09 14:31:33 elrond pulseaudio[11933]: Most likely this is a bug in the ALSA driver 'snd_usb_audio'. Please report this issue to the ALSA developers. Jun 09 14:31:33 elrond pulseaudio[11933]: ALSA woke us up to write new data to the device, but there was actually nothing to write. Message-ID: <20200609213709.68678F8028C@xxxxxxxxxxxxxx> Content-Type: text/plain; charset="us-ascii" alsa-project/alsa-lib issue #57 was opened from danieloppenlander: I ran across an error in my journalctl on Ubuntu 20.04. It said to report a bug. Here is my alsa-info.sh output: http://alsa-project.org/db/?f=6b505aa5138f2a974037ab5c3a89e1605807df97 Issue URL : https://github.com/alsa-project/alsa-lib/issues/57 Repository URL: https://github.com/alsa-project/alsa-lib ------------------------------ Message: 6 Date: Tue, 9 Jun 2020 23:37:50 +0200 (CEST) From: GitHub issues - edited <github@xxxxxxxxxxxxxxxx> To: alsa-devel@xxxxxxxxxxxxxxxx Subject: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail. Jun 09 14:31:33 elrond pulseaudio[11933]: Most likely this is a bug in the ALSA driver 'snd_usb_audio'. Please report this issue to the ALSA developers. Jun 09 14:31:33 elrond pulseaudio[11933]: ALSA woke us up to write new data to the device, but there was actually nothing to write. Message-ID: <20200609213750.BD8BDF80292@xxxxxxxxxxxxxx> Content-Type: text/plain; charset="us-ascii" alsa-project/alsa-lib issue #57 was edited from danieloppenlander: I ran across an error in my journalctl on Ubuntu 20.04. It said to report a bug. Here is my alsa-info.sh output: http://alsa-project.org/db/?f=6b505aa5138f2a974037ab5c3a89e1605807df97 Here is the journalctl message: ``` We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail. Jun 09 14:31:33 elrond pulseaudio[11933]: Most likely this is a bug in the ALSA driver 'snd_usb_audio'. Please report this issue to the ALSA developers. Jun 09 14:31:33 elrond pulseaudio[11933]: ALSA woke us up to write new data to the device, but there was actually nothing to write. ``` Issue URL : https://github.com/alsa-project/alsa-lib/issues/57 Repository URL: https://github.com/alsa-project/alsa-lib ------------------------------ Message: 7 Date: Tue, 9 Jun 2020 23:38:12 +0200 (CEST) From: GitHub issues - edited <github@xxxxxxxxxxxxxxxx> To: alsa-devel@xxxxxxxxxxxxxxxx Subject: ALSA journalctl error. Message-ID: <20200609213812.E8B5EF8029A@xxxxxxxxxxxxxx> Content-Type: text/plain; charset="us-ascii" alsa-project/alsa-lib issue #57 was edited from danieloppenlander: I ran across an error in my journalctl on Ubuntu 20.04. It said to report a bug. Here is my alsa-info.sh output: http://alsa-project.org/db/?f=6b505aa5138f2a974037ab5c3a89e1605807df97 Here is the journalctl message: ``` We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail. Jun 09 14:31:33 elrond pulseaudio[11933]: Most likely this is a bug in the ALSA driver 'snd_usb_audio'. Please report this issue to the ALSA developers. Jun 09 14:31:33 elrond pulseaudio[11933]: ALSA woke us up to write new data to the device, but there was actually nothing to write. ``` Issue URL : https://github.com/alsa-project/alsa-lib/issues/57 Repository URL: https://github.com/alsa-project/alsa-lib ------------------------------ Message: 8 Date: Tue, 9 Jun 2020 23:38:23 +0200 (CEST) From: GitHub issues - edited <github@xxxxxxxxxxxxxxxx> To: alsa-devel@xxxxxxxxxxxxxxxx Subject: ALSA journalctl Error Message-ID: <20200609213823.4B065F802A7@xxxxxxxxxxxxxx> Content-Type: text/plain; charset="us-ascii" alsa-project/alsa-lib issue #57 was edited from danieloppenlander: I ran across an error in my journalctl on Ubuntu 20.04. It said to report a bug. Here is my alsa-info.sh output: http://alsa-project.org/db/?f=6b505aa5138f2a974037ab5c3a89e1605807df97 Here is the journalctl message: ``` We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail. Jun 09 14:31:33 elrond pulseaudio[11933]: Most likely this is a bug in the ALSA driver 'snd_usb_audio'. Please report this issue to the ALSA developers. Jun 09 14:31:33 elrond pulseaudio[11933]: ALSA woke us up to write new data to the device, but there was actually nothing to write. ``` Issue URL : https://github.com/alsa-project/alsa-lib/issues/57 Repository URL: https://github.com/alsa-project/alsa-lib ------------------------------ Subject: Digest Footer _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ------------------------------ End of Alsa-devel Digest, Vol 160, Issue 72 *******************************************
