issue with TWL4030

issue with TWL4030

[Grazvydas Ignotas]

Hi,

there seems to be a problem with TWL4030 hw_param programming, which
is easy to reproduce over OSS emulation with this simple program:

int oss_dev = open("/dev/dsp", O_WRONLY);
int stereo = 1, bits = 16, rate = 44100;
ioctl(oss_dev, SNDCTL_DSP_SETFMT, &bits);
ioctl(oss_dev, SNDCTL_DSP_SPEED,  &rate);
ioctl(oss_dev, SNDCTL_DSP_STEREO, &stereo);
write(oss_dev, somebuff, sizeof(somebuff));

The above program ends up playing at 8kHz, instead of expected 44kHz.
I did some call tracing and got this:
[ 1092.246032] soc_pcm_hw_params, rate 8000
[ 1092.250122] twl4030_hw_params
[ 1092.253234]   set rate 8000
[ 1092.256103]   configured 1
[ 1092.259368] soc_pcm_hw_params, rate 8000
[ 1092.263427] twl4030_hw_params
[ 1092.266845] soc_pcm_hw_params, rate 44100
[ 1092.270965] twl4030_hw_params
[ 1094.459106] twl4030_shutdown
[ 1094.462036]   configured 0

So it looks like twl4030->configured is the culprit of this, removing
it solves the problem, but I guess that will break something else. Any
ideas how to properly fix this?

Gražvydas
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: issue with TWL4030

[Mark Brown]

On Sat, Jul 03, 2010 at 01:50:50AM +0300, Grazvydas Ignotas wrote:

> there seems to be a problem with TWL4030 hw_param programming, which
> is easy to reproduce over OSS emulation with this simple program:

OSS emulation is strongly disrecommended due to the fact that it
repeatedly reprograms things using partially valid configurations.  Some
drivers will refuse to run with it.

> So it looks like twl4030->configured is the culprit of this, removing
> it solves the problem, but I guess that will break something else. Any
> ideas how to properly fix this?

Usually the best thing is to sidestep the issue by avoiding using OSS.

Re: issue with TWL4030

[Grazvydas Ignotas]

On Sat, Jul 3, 2010 at 3:06 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Sat, Jul 03, 2010 at 01:50:50AM +0300, Grazvydas Ignotas wrote:
>
>> there seems to be a problem with TWL4030 hw_param programming, which
>> is easy to reproduce over OSS emulation with this simple program:
>
> OSS emulation is strongly disrecommended due to the fact that it
> repeatedly reprograms things using partially valid configurations.  Some
> drivers will refuse to run with it.

Well it used to work fine on OMAP+TWL until one of Peter's rework
patches, I guess 6b87a91f (haven't really bisected), hope we can find
some solution. We have some closed OSS programs that we can't drop,
unfortunately. I know userspace OSS emulation solutions exist, but it
wouldn't hurt to have more options.

Re: issue with TWL4030

[Mark Brown]

On 3 Jul 2010, at 23:32, Grazvydas Ignotas <notasas@gmail.com> wrote:

> On Sat, Jul 3, 2010 at 3:06 AM, Mark Brown
> <broonie@opensource.wolfsonmicro.com> wrote:
>> On Sat, Jul 03, 2010 at 01:50:50AM +0300, Grazvydas Ignotas wrote:
>> 
>>> there seems to be a problem with TWL4030 hw_param programming, which
>>> is easy to reproduce over OSS emulation with this simple program:
>> 
>> OSS emulation is strongly disrecommended due to the fact that it
>> repeatedly reprograms things using partially valid configurations.  Some
>> drivers will refuse to run with it.
> 
> Well it used to work fine on OMAP+TWL until one of Peter's rework
> patches, I guess 6b87a91f (haven't really bisected), hope we can find
> some solution. We have some closed OSS programs that we can't drop,
> unfortunately. I know userspace OSS emulation solutions exist, but it
> wouldn't hurt to have more options.

OSS is dying in mainline, distributions are desupporting it and it's just painful all round to carry the bodges for it in kernel, so I really would recommend exploring the userspace solutions if you need to interoperate with this unfixable userspace stuff. I'd anticipate you will run into further issues going forward with kernel side changes, and it gives you more room to do things like soft mixing in your userspace stack too. 

Re: issue with TWL4030

[peter.ujfalusi]

Hi,

________________________________________
From: ext Grazvydas Ignotas [notasas@gmail.com]
Sent: Saturday, July 03, 2010 5:32 PM
To: Mark Brown
Cc: Ujfalusi Peter (Nokia-MS/Tampere); alsa-devel
Subject: Re: [alsa-devel] issue with TWL4030

> On Sat, Jul 3, 2010 at 3:06 AM, Mark Brown
> <broonie@opensource.wolfsonmicro.com> wrote:
> > On Sat, Jul 03, 2010 at 01:50:50AM +0300, Grazvydas Ignotas wrote:
> >
>> there seems to be a problem with TWL4030 hw_param programming, which
>> is easy to reproduce over OSS emulation with this simple program:
> >
> > OSS emulation is strongly disrecommended due to the fact that it
> > repeatedly reprograms things using partially valid configurations.  Some
> > drivers will refuse to run with it.
> 
> Well it used to work fine on OMAP+TWL until one of Peter's rework
> patches, I guess 6b87a91f (haven't really bisected), hope we can find
> some solution. We have some closed OSS programs that we can't drop,
> unfortunately. I know userspace OSS emulation solutions exist, but it
> wouldn't hurt to have more options.

Hmm.. The twl4030->configured meant to protect the reconfiguration of the
codec when the second stream tries to start with different properties than
the already running first (master) stream (and it has been introduced quite
some time ago).
The rest of the hassle around the hw param and parameter locking was to
fix gstreamer's way of starting full duplex operation.

While I agree with Mark, that OSS emulation should be phased out now (it's 2010)..
However, extending the state handling might fix your problem, but it complicates
things greatly, which can lead to more problems...
What I can think of is:
If only one (the master) stream has been opened, and the stream is not running (the
pcm_trigger has not been called yet), than we could allow reconfiguration of the codec.
Might work OK, but it might cause some problems under different scenario.

--
Peter

Re: issue with TWL4030

[Liam Girdwood]

On Mon, 2010-07-05 at 23:13 +0200, peter.ujfalusi@nokia.com wrote:

> While I agree with Mark, that OSS emulation should be phased out now (it's 2010)..
> However, extending the state handling might fix your problem, but it complicates
> things greatly, which can lead to more problems...

Just to further clarify wrt OSS emulation here, it was decided at last
years Plumbers conference audio session (where Mark and I were both in
attendance along with Paul Davis, Lennart Poettering and a lot of distro
folks) that the distros would start dropping OSS support from their
default installs (although OSS could still be installed manually later).

In light of this, new ASoC code will no longer be tested against OSS
emulation. It's just too much of a pain to implement and test for too
little benefit for us (we will still accept OSS emulation patches
though).

Please port your app to ALSA, it's really the easiest option (look at
aplay.c for programming sequence). 

Thanks

Liam
-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

Re: issue with TWL4030

[Grazvydas Ignotas]

On Tue, Jul 6, 2010 at 12:13 AM,  <peter.ujfalusi@nokia.com> wrote:
> What I can think of is:
> If only one (the master) stream has been opened, and the stream is not running (the
> pcm_trigger has not been called yet), than we could allow reconfiguration of the codec.
> Might work OK, but it might cause some problems under different scenario.

This sounds good to me, I wonder what that different scenario could
be. Is it worth trying implementing that (i.e. would such patch be
even considered)?

On Tue, Jul 6, 2010 at 12:40 AM, Liam Girdwood <lrg@slimlogic.co.uk> wrote:
> Please port your app to ALSA, it's really the easiest option (look at
> aplay.c for programming sequence).

The problem is not new apps, but legacy ones. Pandora is spiritual
successor of Gamepark/GPH devices, which only had OSS drivers, so we
have many apps/games outputing through OSS, some of them without
source available. We will have to provide userspace OSS emulation at
least, and in-kernel OSS emulation is attractive because of
performance reasons.

Re: issue with TWL4030

[Peter Ujfalusi]

Hi,

On Tuesday 06 July 2010 01:51:20 ext Grazvydas Ignotas wrote:
> On Tue, Jul 6, 2010 at 12:13 AM,  <peter.ujfalusi@nokia.com> wrote:
> > What I can think of is:
> > If only one (the master) stream has been opened, and the stream is not
> > running (the pcm_trigger has not been called yet), than we could allow
> > reconfiguration of the codec. Might work OK, but it might cause some
> > problems under different scenario.
> 
> This sounds good to me, I wonder what that different scenario could
> be.

It's hard to say what scenario, but if we start to fix application bugs in 
driver level, than surely it will not going to be an easy task.

> Is it worth trying implementing that (i.e. would such patch be
> even considered)?

As of it now, I'm not planning to add workaround to this, since I can not really 
test if it is working correctly.
Also I just came back from holiday, and my mailbox is quite full, so do not 
expect that I can even take a look at this in the near future.

Having said that.. since I do care about the twl4030 codec driver (and it's 
users), I will try to allocate time to fix it for you.

> On Tue, Jul 6, 2010 at 12:40 AM, Liam Girdwood <lrg@slimlogic.co.uk> wrote:
> > Please port your app to ALSA, it's really the easiest option (look at
> > aplay.c for programming sequence).
> 
> The problem is not new apps, but legacy ones. Pandora is spiritual
> successor of Gamepark/GPH devices, which only had OSS drivers, so we
> have many apps/games outputing through OSS, some of them without
> source available. We will have to provide userspace OSS emulation at
> least, and in-kernel OSS emulation is attractive because of
> performance reasons.

I would advice to use the userspace emulation for now. There might be kernel 
level fix for this, but it will take time.

-- 
Péter

Re: issue with TWL4030

[Grazvydas Ignotas]

hello,

On Mon, Jul 12, 2010 at 1:12 PM, Peter Ujfalusi
<peter.ujfalusi@nokia.com> wrote:
> On Tuesday 06 July 2010 01:51:20 ext Grazvydas Ignotas wrote:
>> On Tue, Jul 6, 2010 at 12:13 AM,  <peter.ujfalusi@nokia.com> wrote:
>> > What I can think of is:
>> > If only one (the master) stream has been opened, and the stream is not
>> > running (the pcm_trigger has not been called yet), than we could allow
>> > reconfiguration of the codec. Might work OK, but it might cause some
>> > problems under different scenario.
>>
>> This sounds good to me, I wonder what that different scenario could
>> be.
>
> It's hard to say what scenario, but if we start to fix application bugs in
> driver level, than surely it will not going to be an easy task.

Just to clarify, from OSS point of view the app is correct (and rather
typical), it first sets sample format, then rate and channel count.
There is no way to set all of these at once using OSS API from what I
understand.

>> Is it worth trying implementing that (i.e. would such patch be
>> even considered)?
>
> As of it now, I'm not planning to add workaround to this, since I can not really
> test if it is working correctly.

If you can build a kernel with OSS emulation enabled it's trivial to
test, just run 'mplayer -ao oss' or build the test I sent before (just
include linux/souncard.h, no libraries required).

> Also I just came back from holiday, and my mailbox is quite full, so do not
> expect that I can even take a look at this in the near future.
>
> Having said that.. since I do care about the twl4030 codec driver (and it's
> users), I will try to allocate time to fix it for you.

Thanks!

>> On Tue, Jul 6, 2010 at 12:40 AM, Liam Girdwood <lrg@slimlogic.co.uk> wrote:
>> > Please port your app to ALSA, it's really the easiest option (look at
>> > aplay.c for programming sequence).
>>
>> The problem is not new apps, but legacy ones. Pandora is spiritual
>> successor of Gamepark/GPH devices, which only had OSS drivers, so we
>> have many apps/games outputing through OSS, some of them without
>> source available. We will have to provide userspace OSS emulation at
>> least, and in-kernel OSS emulation is attractive because of
>> performance reasons.
>
> I would advice to use the userspace emulation for now. There might be kernel
> level fix for this, but it will take time.
>
> --
> Péter
>

Re: issue with TWL4030

[Peter Ujfalusi]

On Monday 12 July 2010 23:26:32 ext Grazvydas Ignotas wrote:
> > As of it now, I'm not planning to add workaround to this, since I can not
> > really test if it is working correctly.
> 
> If you can build a kernel with OSS emulation enabled it's trivial to
> test, just run 'mplayer -ao oss' or build the test I sent before (just
> include linux/souncard.h, no libraries required).

Oh yes, fortunately I do have mplayer laying around :D

> 
> > Also I just came back from holiday, and my mailbox is quite full, so do
> > not expect that I can even take a look at this in the near future.
> > 
> > Having said that.. since I do care about the twl4030 codec driver (and
> > it's users), I will try to allocate time to fix it for you.
> 
> Thanks!

Thank me when it is done ;)
I do have some urgent issues to handle before I can take a look, but I think it 
can be done.

-- 
Péter

Re: issue with TWL4030

[Raymond Yau]

2010/7/6 <peter.ujfalusi@nokia.com>

> Hi,
>
> ________________________________________
> From: ext Grazvydas Ignotas [notasas@gmail.com]
> Sent: Saturday, July 03, 2010 5:32 PM
> To: Mark Brown
> Cc: Ujfalusi Peter (Nokia-MS/Tampere); alsa-devel
> Subject: Re: [alsa-devel] issue with TWL4030
>
> > On Sat, Jul 3, 2010 at 3:06 AM, Mark Brown
> > <broonie@opensource.wolfsonmicro.com> wrote:
> > > On Sat, Jul 03, 2010 at 01:50:50AM +0300, Grazvydas Ignotas wrote:
> > >
> >> there seems to be a problem with TWL4030 hw_param programming, which
> >> is easy to reproduce over OSS emulation with this simple program:
> > >
> > > OSS emulation is strongly disrecommended due to the fact that it
> > > repeatedly reprograms things using partially valid configurations.
>  Some
> > > drivers will refuse to run with it.
> >
> > Well it used to work fine on OMAP+TWL until one of Peter's rework
> > patches, I guess 6b87a91f (haven't really bisected), hope we can find
> > some solution. We have some closed OSS programs that we can't drop,
> > unfortunately. I know userspace OSS emulation solutions exist, but it
> > wouldn't hurt to have more options.
>
> Hmm.. The twl4030->configured meant to protect the reconfiguration of the
> codec when the second stream tries to start with different properties than
> the already running first (master) stream (and it has been introduced quite
> some time ago).
> The rest of the hassle around the hw param and parameter locking was to
> fix gstreamer's way of starting full duplex operation.
>
> While I agree with Mark, that OSS emulation should be phased out now (it's
> 2010)..
> However, extending the state handling might fix your problem, but it
> complicates
> things greatly, which can lead to more problems...
> What I can think of is:
> If only one (the master) stream has been opened, and the stream is not
> running (the
> pcm_trigger has not been called yet), than we could allow reconfiguration
> of the codec.
> Might work OK, but it might cause some problems under different scenario.
>
>
The OSS emulation call driver's hw_params many time when the OSS program or
SDL try to probe the supported rate , format and channels

Not easy for the driver to 100% compatible with OSS 3.8 since the default is
mono ,U8 and 8000Hz when you use  "cat  foo.wav > /dev/dsp" or "cat /dev/dsp
> foo.wav"

Re: issue with TWL4030

[Peter Ujfalusi]

Hi,

On Tuesday 06 July 2010 02:24:50 ext Raymond Yau wrote:
> The OSS emulation call driver's hw_params many time when the OSS program or
> SDL try to probe the supported rate , format and channels
> 
> Not easy for the driver to 100% compatible with OSS 3.8 since the default
> is mono ,U8 and 8000Hz when you use  "cat  foo.wav > /dev/dsp" or "cat
> /dev/dsp > foo.wav"

I agree with you.
What I plan to do is to allow several hw_params call on the master (first) 
stream until the point when the playback is actually started.
I need to check how does the consequent hw_parmas looks like. Do they retain the 
already configured parameters? What I mean is that at the last hw_parmas call is 
it so that all the needed information sent to the driver?

Thanks,
Péter