We were woken up with POLLOUT set

Stuart Naylor stuartiannaylor at outlook.com
Tue Jun 9 23:44:05 CEST 2020 

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 at alsa-project.org<mailto:alsa-devel-request at alsa-project.org>
Sent: 09 June 2020 22:40
To: alsa-devel at alsa-project.org<mailto:alsa-devel at alsa-project.org>
Subject: Alsa-devel Digest, Vol 160, Issue 72

Send Alsa-devel mailing list submissions to
        alsa-devel at alsa-project.org

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 at alsa-project.org

You can reach the person managing the list at
        alsa-devel-owner at alsa-project.org

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 at ti.com>
To: Mark Brown <broonie at kernel.org>
Cc: robh at kernel.org, alsa-devel at alsa-project.org,
        devicetree at vger.kernel.org, linux-kernel at vger.kernel.org,
        tiwai at suse.com, lgirdwood at gmail.com
Subject: Re: [RFC PATCH 0/2] TAS2563 DSP Firmware Loader
Message-ID: <6d6aaed3-dac8-e1ec-436c-9b04273df2b3 at ti.com>
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 at kernel.org>
To: Dan Murphy <dmurphy at ti.com>
Cc: robh at kernel.org, alsa-devel at alsa-project.org,
        devicetree at vger.kernel.org, linux-kernel at vger.kernel.org,
        tiwai at suse.com, lgirdwood at gmail.com
Subject: Re: [RFC PATCH 0/2] TAS2563 DSP Firmware Loader
Message-ID: <20200609181615.GR4583 at sirena.org.uk>
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 at kernel.org>
To: Dan Murphy <dmurphy at ti.com>
Cc: robh at kernel.org, alsa-devel at alsa-project.org,
        devicetree at vger.kernel.org, linux-kernel at vger.kernel.org,
        tiwai at suse.com, lgirdwood at gmail.com
Subject: Re: [RFC PATCH 1/2] dt-bindings: tas2562: Add firmware
        support for tas2563
Message-ID: <20200609184734.GS4583 at sirena.org.uk>
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 at ti.com>
To: Mark Brown <broonie at kernel.org>
Cc: robh at kernel.org, alsa-devel at alsa-project.org,
        devicetree at vger.kernel.org, linux-kernel at vger.kernel.org,
        tiwai at suse.com, lgirdwood at gmail.com
Subject: Re: [RFC PATCH 1/2] dt-bindings: tas2562: Add firmware
        support for tas2563
Message-ID: <014b85b5-677b-569a-4eb2-74526d3f00bc at ti.com>
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 at alsa-project.org>
To: alsa-devel at alsa-project.org
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 at alsa1.perex.cz>
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 at alsa-project.org>
To: alsa-devel at alsa-project.org
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 at alsa1.perex.cz>
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 at alsa-project.org>
To: alsa-devel at alsa-project.org
Subject: ALSA journalctl error.
Message-ID: <20200609213812.E8B5EF8029A at alsa1.perex.cz>
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 at alsa-project.org>
To: alsa-devel at alsa-project.org
Subject: ALSA journalctl Error
Message-ID: <20200609213823.4B065F802A7 at alsa1.perex.cz>
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 at alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel


------------------------------

End of Alsa-devel Digest, Vol 160, Issue 72
*******************************************

More information about the Alsa-devel mailing list