On Tue, Oct 05, 2010 at 05:48:08PM +0000, Jacob Meuser wrote:
> On Tue, Oct 05, 2010 at 04:27:59PM +0200, Landry Breuil wrote:
> > On Tue, Oct 05, 2010 at 02:15:29PM +0000, Jacob Meuser wrote:
> > > On Mon, Oct 04, 2010 at 05:11:47PM +0000, Jacob Meuser wrote:
> > > > On Mon, Oct 04, 2010 at 05:57:50PM +0200, Tobias Ulmer wrote:
> > > > > I'm against adding any cargo cult stuff like this and would rather see
> > > > > someone who knows aucat and the audio stuff figure out why it skips 
> > > > > and
> > > > > clicks like mad. I doubt it's mpds fault.
> > > > > 
> > > > > But that's probably not going to happen... Oh well. Commit it if you
> > > > > really have to.
> > > > 
> > > > this is the first I heard of mpd skipping with auich.  skipping
> > > > was reported with azalia, but since  I haven't heard anything about
> > > > that since the interrupt issue was dealt with, I figured that's
> > > > what was causing it.
> > > > 
> > > > anyway, I have no idea how to use mpd, and don't really care enough
> > > > to figure it out on my own.  there are many mpd users here, afaik.
> > > 
> > > so, I pkg_add'd mpd and mpc ...
> > > 
> > > $ mpd
> > > log: problem opening log file "/var/log/mpd/mpd.log" (config line 37) for 
> > > writing
> > > Abort trap (core dumped)
> > > $ 
> > 
> > oh come on.
> > 
> > pkg_info -M mpd will show you that by default it's supposed to be
> > launched by root, and /etc/mpd.conf has shitload of comments.
> 
> no, it tells you how to launch it from rc.local.  it does not say mpd
> will crash and burn if you start it as a regular user without changing
> the config file.

Hey Jacob, cool down a bit ;)

The core dump comes from the fact that it uses glib error message
routines that are intended for debugging. Thanks to David, that has
been fixed upstream recently.

Another stupid thing you will likely run into is that it doesn't create
some files on its own. "touch" them...

Now, mpd is a daemon and the default config reflects that. You can of
course change it, but that's not how upstream distributes it. I don't
like the Debian way of doing things, and I'm probably not alone here...

Anyway, I don't know what Davids exact problem is. I can only describe
mine.

I have a cmpci(4) which usually works great:
cmpci0 at pci0 dev 16 function 0 "C-Media Electronics CMI8738/C3DX
Audio" rev 0x10: apic 2 int 19 (irq 11)

Under heavy IO + crypto softraid, it sometimes skips. That's ok by me, I
don't expect a 2x500mhz machine to run cvs up and backups and nfs etc
while providing excellent audio.

What is new since a couple of months (guessing 2ish), it goes into an
endless clicking noise intermixed with music and doesn't recover from
that even if the machine is idle again.

It's not that easy to reproduce, I have to do quite a few things in
parallel to get it there, and often it doesn't happen at all.

mpc stop && sleep 2 && mpc play fixes it for a short time under load.
There is a noticable delay between the end of clicking and the end of
music (~.3 sec or so)

Afair play.errors increases during the "clicking time".

What makes me think it's not mpd is that it also happens with mplayer.
The difference is that mplayer consumes 1% cpu compared to 10% mpd. It
just happens less often.

I can't really pin it down, and I didn't want to write a bug report
which basically consists of wild guessing. I'll try without aucat for a
while to check if that has any influence.

Davids problem sounds different to mine, could well be they are unrelated.

Tobias

> 
> > And yes, mpd's error handling is totally awful. MAINTAINER is aware of
> > it.
> > 
> > Landry
> 
> and so why should I care, really?  if it doesn't work as a regular user
> try running it as root?  talk about "oh come on" ...
> 
> -- 
> jake...@sdf.lonestar.org
> SDF Public Access UNIX System - http://sdf.lonestar.org
> 

Reply via email to