[CM] snd: cannot set hardware parameters for default

[Fernando Lopez-Lezcano]

On Wed, 2008-01-23 at 19:14 +0100, Kjetil S. Matheussen wrote:
> On Wed, 23 Jan 2008, Fernando Lopez-Lezcano wrote:
> > On Wed, 2008-01-23 at 10:15 +0100, andersvi@extern.uio.no wrote:
> >> Indeed, there has been something weird with snd and sndplay for some
> >> time.
> >>
> >> Ive only tested jack-enabled versions.  Since some time near spring
> >> 2007, neither recent self-built jack-enabled versions or disted
> >> versions from planetccrma (tested with snd-utils rpms for fc6 or fc7
> >> from june 8th and december 7th.)  function without jack running.
> >>
> >> Trying to use any of them without jack makes errors which resemble the
> >> one Funny Zen described.
> >
> > Yep.
> >
> > My wish list for snd would include something like dropping the alsa
> > driver and using something else, higher level of course. What? Hmmm,
> > pulseaudio is being used in f8 but I know nothing about it. One idea
> > that occurred to me a while ago is to try to see if libecasound can be
> >
> Yes, but I think the audio in sndlib is excellent already, I have
> used it for providing sound to both ceres and mammut, and
> recommended it as a lightweight alternative to portaudio many times.
> The alsa backend isn't allways working very well though, but running
> alsa with oss emulation solves that problem just fine. The
> trick is just not to use the --with-alsa commandline when compiling
> snd. 

Yuck, if I may say :-) That does not solve the problem from the point of
view of the program - it merely does not use the code that has the
problem (which is sort of solving it, of course). 

> Thats how snd-ls is configured. Not that the alsa backend
> in snd is bad programmed, you probably did an excellent job,
> but the alsa api is horrible, and snd isn't the only program
> with not allways working alsa backend. 

It surely looks like I did not do a good job, otherwise we would not see
the problems we see. I seem to remember it used to work well, I don't
know what changed that broke it, or when. 

The original code used the hardware interface (ie: accessed the hardware
device directly and used the already existing internals of snd to do
format conversion, etc, etc), has that changed? The only thing missing
from the alsa code (which I remember) was handling of interleaved
soundcards - I think that pretty much the only hardware that has/had
that was the RME cards, which did not exist when I originally wrote the
alsa backend. With those it would fail and I was hoping someone would
fix that :-)

I should probably try to look again at the current code and see what is
wrong with it (the symptom is snd trying to program the soundcard with
parameters that don't match its capabilities - my original code used to
probe for them fine). But where do I find time? :-p

> Wine, juce, pd, mplayer,
> from the top of my head, are others programs who have or have had
> similar problems.

Yep. The alsa api is not horrible but it is very complicated. Most
programmers don't spend the necessary time to understand it (I did not,
he he he :-)

> > used to provide the audio i/o services. Ecasound is a very good command
> > line player (and "digital audio workstation"), properly supports alsa
> > and jack and I have found it to be very stable and reliable...
> 
> Snd's jack backend is tuned quite a lot for snd, plus that
> it runs with sched_fifo priority and also runs its own watchdog,
> so I'm not so sure about replacing the jack part. But well. :-)

Yes, the jack part works fine. But alsa does not. Maybe it is easy to
fix? At this point I only use jack so I don't see the problems. 

I suggested the ecasound api (just a suggestion, I don't know if it
could be grafted into snd) because it handles all apis equally well and
is sched_fifo optimized for all as well. I don't know if that would also
add unnecessary complexity to snd due to its multiplatform support. 

-- Fernando