[Fwd: Re: [MPlayer-dev-eng] AV out of sync with "-ao alsa" in gmplayer, mplayer works ok]

[Fwd: Re: [MPlayer-dev-eng] AV out of sync with "-ao alsa" in gmplayer, mplayer works ok]

[Lee Revell]

OK, I trolled the mplayer dev list, and got this response. ;-)

Are Reimar's statements about memory leaks valid?

Lee

-------- Forwarded Message --------
From: Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de>
Reply-To: mplayer-dev-eng@mplayerhq.hu
To: mplayer-dev-eng@mplayerhq.hu
Subject: Re: [MPlayer-dev-eng] AV out of sync with "-ao alsa" in
gmplayer, mplayer works ok
Date: Wed, 29 Dec 2004 09:41:01 +0100
Hi,
On Tue, Dec 28, 2004 at 10:55:33PM -0500, Lee Revell wrote:
> Using 1.0pre6, "gmplayer -ao alsa" results in the sound and video being
> out of sync.  "mplayer -ao alsa" works fine, as does "-ao oss" with
> either mplayer or gmplayer.

Are you sure this isn't caused either by different settings in gmplayer
or because the computer is too slow? Please provide a full -v log.

> This is quite annoying, as I was expecting to FINALLY have a gmplayer
> release usable with ALSA.  Previous versions were unusable due to that
> stupid "/dev/mixer" bug.
> 
> What's the deal?  Why is it so hard for the mplayer developers to get
> ALSA support right?  I hack on ALSA a lot, so if there is some problem
> with the ALSA API, we would like to hear about it on the mailing list.

Yes, please fix the huge memory leak with ALSA output, especially when
changing the volume (it is cause by the call to snd_mixer_load, but I
couldn't find an ALSA function that frees that memory again
snd_mixer_free has absolutely no effect :-( ).
Also the problem is more that the Gui is not well supported.

> Or do you all just use OSS still?

The OSS interface is actually a lot nicer, so yes it is supported better.

> From the users perspective things like this make ALSA look bad, while
> the problem is really with gmplayer's shoddy ALSA support.

>From what I saw of ALSA as a developer it is bad, but that's a bit of
personal opinion of course. What I refer to is very slow software mixing, no way to use it
without getting into synchronization hell because it uses threads,
hundreds of function calls to initialize it, and those memory leaks that
to my best knowledge seem to come from the alsa lib (my best guess is
that this is because like in conf.c, in _snd_config_make pointers
are overwritten without being freed first).
What makes it a bit difficult to use it that it's quite difficult to
find the function that is supposed to free things again, they e.g.
often aren't located directly below the allocation function in the
headers, and that there is a snd_mixer_load function but no
snd_mixer_unload as I would expect it.
All these things together made me give up on ALSA.

Greetings,
Reimar Döffinger

_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng@mplayerhq.hu
http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: [Fwd: Re: [MPlayer-dev-eng] AV out of sync with "-ao alsa" in gmplayer, mplayer works ok]

[Måns Rullgård]

Lee Revell <rlrevell@joe-job.com> writes:

> OK, I trolled the mplayer dev list, and got this response. ;-)
>
> Are Reimar's statements about memory leaks valid?

No.  I regularly run my player under valgrind, and it reports no ALSA
related leaks.  I also run the same player for weeks on end, and the
memory usage stays below 4MB, after opening, playing a bit, and
closing the sound device thousands of times.

> Hi,
> On Tue, Dec 28, 2004 at 10:55:33PM -0500, Lee Revell wrote:
>> Using 1.0pre6, "gmplayer -ao alsa" results in the sound and video being
>> out of sync.  "mplayer -ao alsa" works fine, as does "-ao oss" with
>> either mplayer or gmplayer.
>
> Are you sure this isn't caused either by different settings in gmplayer
> or because the computer is too slow? Please provide a full -v log.
>
>> This is quite annoying, as I was expecting to FINALLY have a gmplayer
>> release usable with ALSA.  Previous versions were unusable due to that
>> stupid "/dev/mixer" bug.
>> 
>> What's the deal?  Why is it so hard for the mplayer developers to get
>> ALSA support right?  I hack on ALSA a lot, so if there is some problem
>> with the ALSA API, we would like to hear about it on the mailing list.
>
> Yes, please fix the huge memory leak with ALSA output,

Never seen that one.  Could be a leak in mplayer's ALSA support, of
course.

> especially when changing the volume (it is cause by the call to
> snd_mixer_load, but I couldn't find an ALSA function that frees that
> memory again snd_mixer_free has absolutely no effect :-( ).  Also
> the problem is more that the Gui is not well supported.
>
>> Or do you all just use OSS still?
>
> The OSS interface is actually a lot nicer, so yes it is supported better.

LOL

>> From the users perspective things like this make ALSA look bad, while
>> the problem is really with gmplayer's shoddy ALSA support.
>
>>From what I saw of ALSA as a developer it is bad, but that's a bit of
> personal opinion of course. What I refer to is very slow software

Who said what here?

> mixing, no way to use it without getting into synchronization hell
> because it uses threads,

Oh, never forget that the mplayer folks hate threads.

> hundreds of function calls to initialize it, and those memory leaks
> that to my best knowledge seem to come from the alsa lib (my best
> guess is that this is because like in conf.c, in _snd_config_make
> pointers are overwritten without being freed first).  What makes it
> a bit difficult to use it that it's quite difficult to find the
> function that is supposed to free things again, they e.g.  often
> aren't located directly below the allocation function in the
> headers, and that there is a snd_mixer_load function but no
> snd_mixer_unload as I would expect it.

OK, the documentation could be better.

> All these things together made me give up on ALSA.

I'll skip the insult this time.

-- 
Måns Rullgård
mru@inprovide.com



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: [Fwd: Re: [MPlayer-dev-eng] AV out of sync with "-ao alsa" in gmplayer, mplayer works ok]

[Lee Revell]

On Wed, 2004-12-29 at 11:19 +0100, Måns Rullgård wrote:
> >> From the users perspective things like this make ALSA look bad, while
> >> the problem is really with gmplayer's shoddy ALSA support.
> >

Me

> >>From what I saw of ALSA as a developer it is bad, but that's a bit of
> > personal opinion of course. What I refer to is very slow software
> 

Reimar

> Who said what here?
> 

Anyway, sorry for my previous tone, I would really like to improve the
situation, by helping the mplayer developers get good alsa support.

Lee




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: [Fwd: Re: [MPlayer-dev-eng] AV out of sync with "-ao alsa" in gmplayer, mplayer works ok]

[Reimar Döffinger]

Hi,

Måns Rullgård <mru <at> inprovide.com> writes:
> Lee Revell <rlrevell <at> joe-job.com> writes:
> > OK, I trolled the mplayer dev list, and got this response. 
> >
> > Are Reimar's statements about memory leaks valid?
> 
> No.  I regularly run my player under valgrind, and it reports no ALSA
> related leaks.  I also run the same player for weeks on end, and the
> memory usage stays below 4MB, after opening, playing a bit, and
> closing the sound device thousands of times.

And how about opening and closing the mixer thousands of times? I posted a
stripped-down sample code that ahould show the problem a few days ago...

> > On Tue, Dec 28, 2004 at 10:55:33PM -0500, Lee Revell wrote:
[...]
> >> What's the deal?  Why is it so hard for the mplayer developers to get
> >> ALSA support right?  I hack on ALSA a lot, so if there is some problem
> >> with the ALSA API, we would like to hear about it on the mailing list.
> >
> > Yes, please fix the huge memory leak with ALSA output,
> 
> Never seen that one.  Could be a leak in mplayer's ALSA support, of
> course.

Well, I didn't say that it was in the ALSA lib. I only said I think so ;-)

> > especially when changing the volume (it is cause by the call to
> > snd_mixer_load, but I couldn't find an ALSA function that frees that
> > memory again snd_mixer_free has absolutely no effect  ).  Also
> > the problem is more that the Gui is not well supported.
> >
> >> Or do you all just use OSS still?
> >
> > The OSS interface is actually a lot nicer, so yes it is supported better.
> 
> LOL

Well, maybe it's just because whoever wrote ao_alsa in MPlayer did it the wrong
way, but compare the size of ao_alsa.c and ao_oss.c and you'll probably see what
I meant...

[...]
> > mixing, no way to use it without getting into synchronization hell
> > because it uses threads,
> 
> Oh, never forget that the mplayer folks hate threads.

Yep, and it's not entirely unjustified...

> > hundreds of function calls to initialize it, and those memory leaks
> > that to my best knowledge seem to come from the alsa lib (my best
> > guess is that this is because like in conf.c, in _snd_config_make
> > pointers are overwritten without being freed first).  What makes it
> > a bit difficult to use it that it's quite difficult to find the
> > function that is supposed to free things again, they e.g.  often
> > aren't located directly below the allocation function in the
> > headers, and that there is a snd_mixer_load function but no
> > snd_mixer_unload as I would expect it.
> 
> OK, the documentation could be better.

Well, that's true for most projects, certainly including MPlayer ;-)
I have to admit I only looked at the headers, I didn't look for/download the
documentation, but I'm not the maintainer of that code anyway...

> > All these things together made me give up on ALSA.
> 
> I'll skip the insult this time.

Thanks :-)

Greetings,
Reimar Döffinger



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: Re: [Fwd: Re: [MPlayer-dev-eng] AV out of sync with "-ao alsa" in gmplayer, mplayer works ok]

[Lee Revell]

On Thu, 2005-01-13 at 15:10 +0000, Reimar Döffinger wrote:
> > > hundreds of function calls to initialize it, and those memory leaks
> > > that to my best knowledge seem to come from the alsa lib (my best
> > > guess is that this is because like in conf.c, in _snd_config_make
> > > pointers are overwritten without being freed first).  What makes it
> > > a bit difficult to use it that it's quite difficult to find the
> > > function that is supposed to free things again, they e.g.  often
> > > aren't located directly below the allocation function in the
> > > headers, and that there is a snd_mixer_load function but no
> > > snd_mixer_unload as I would expect it.
> > 
> > OK, the documentation could be better.
> 
> Well, that's true for most projects, certainly including MPlayer ;-)
> I have to admit I only looked at the headers, I didn't look for/download the
> documentation, but I'm not the maintainer of that code anyway...
> 

Are there any plans to fix the ALSA output so that it doesn't reset the
stream with every xrun?  Since you don't use a realtime thread to handle
the audio there are certain to be some xruns, for example whenever using
the GUI controls in any way or moving the mouse.

http://sourceforge.net/mailarchive/message.php?msg_id=8437146

I am still forced to use the OSS emulation for this reason.

Lee



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: Re: [Fwd: Re: [MPlayer-dev-eng] AV out of sync with "-ao alsa" in gmplayer, mplayer works ok]

[Reimar Döffinger]

Hi,
On Thu, Jan 13, 2005 at 03:11:15PM -0500, Lee Revell wrote:
> Are there any plans to fix the ALSA output so that it doesn't reset the
> stream with every xrun?  Since you don't use a realtime thread to handle
> the audio there are certain to be some xruns, for example whenever using
> the GUI controls in any way or moving the mouse.

xruns just should not happen. Ignoring them seems to be the very wrong
way. Also a real-time thread should not be necessary just to avoid xruns
when only moving the mouse IMHO.
Maybe you can just increase the buffer size somehow? At least for
MPlayer a big buffer should cause no problems.

Greetings,
Reimar Döffinger

P.S.: I wont cc further mails about this to the list, because I don't think this
belongs on alsa-devel.


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: Re: [Fwd: Re: [MPlayer-dev-eng] AV out of sync with "-ao alsa" in gmplayer, mplayer works ok]

[Takashi Iwai]

At Tue, 18 Jan 2005 21:23:09 +0100,
Reimar Döffinger wrote:
> 
> Hi,
> On Thu, Jan 13, 2005 at 03:11:15PM -0500, Lee Revell wrote:
> > Are there any plans to fix the ALSA output so that it doesn't reset the
> > stream with every xrun?  Since you don't use a realtime thread to handle
> > the audio there are certain to be some xruns, for example whenever using
> > the GUI controls in any way or moving the mouse.
> 
> xruns just should not happen. Ignoring them seems to be the very wrong
> way. Also a real-time thread should not be necessary just to avoid xruns
> when only moving the mouse IMHO.

No, it's not guaranteed at all.

> Maybe you can just increase the buffer size somehow? At least for
> MPlayer a big buffer should cause no problems.

The hardware buffer size is limited.  Suppose the hardware which
can have the max buffer size 64kB.  When you play a DVD with 5.1
output, it corresponds to 0.11 second.

The dedicated audio thread works better than the single thread model
because of the following reasons (maybe more):

- It has a large intermediate buffer.  The buffer size can be as large
  as you like.
- It runs only in short time and sleeps.
  This is the preferred behavior for the kernel scheduler.  So, this
  thread may receive higher priority bonus.
- You can change the priority of only audio thread but keep others.


Takashi


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt