[Alsaplayer-devel] 0.99.80-rc2 and future for AlsaPlayer
dominique.michel at citycable.ch
Fri Jul 20 20:10:49 BST 2007
Le Thu, 19 Jul 2007 21:25:23 +0200,
Frank Baumgart <frank.baumgart at gmx.net> a écrit :
> > I want to discuss the future.
> My 2 cents:
> What you listed, to me, is just a "todo" list, not much of a vision for AP.
> There are dozens of file based players around and this is really
> technology of 5 years ago.
> It may be nice to see updates on the GTK(2) GUI but for myself, I could
> not care less.
> Although I have spent much time improving AP, it was not until MadeJ's
> patches that
> I have actually started the GUI interface at all, just out of curiosity.
> Again, it is 2007 now.
> (talk collections/database, musicbrainz, last.fm etc.)
> Strengths of AP:
> - strong backend player
> - stable core
> - relatively efficient
> - stable API support
> - (few) bindings available
> - limited format support
> - lack of maintenance outside the core
> - (few) bindings available
> - not as efficient as it could be (SW mixing, SW volume, balance etc.)
> (this may affect me more than others)
> My priority would be to improve format support and bindings and (if
> someone steps up) provide
> patches for other frontend players if AP can provide some benefit.
> Look at all the more complex frontends, most of them are based on
> backends like mplayer, xine, gstreamer or mad.
I am not sure if I understand well what you mean. They are all depending on
external libs like libsndfile or other. AP is a light player and I think at it
is better if it use directly those libs instead of using some frontend that
will use those libs in its turn.
Another issue I can see is AP speed control. mplayer have a good speed control
but I don know for the other frontends. And even mplayer cannot do reverse
> They do not reinvent the wheel.
I agree, see above.
> The suggestion about floating point conversion (that 10 people on earth
> may be able to identify in
> a double-blind test) looks strange.
It is important to me because of sound quality. You said before at "There are
dozens of file based players around and this is really technology of 5 years
ago.". I don't know the internal of the other players, but I begun to understand
AP, and AP have in this regard a technology of 5 years ago.
The advantage of a floating point sound format is at you get much more dynamic
and a much better resolution at low volume. A sound format such as PCM linear
(CDDA, wav,...) on 16 bits have a dynamic of 96 dB. It is not so much and it
is why all the CD's on the market have a very constant dynamic: full volume.
(And that's sucks!) And when you have a low volume sound, the problem is that it
will not use 16 bits but only 8 bits or even less.
With 24 bits floating point as in jack, you have in all cases 16 bits for the
sound, the other 8 bits tell you the volume. So floating point are much better.
I don't care about your double blind test because many peoples just already
don't recognize for sure if a signal is mono or stereo (the test was done at
least in Switzerland in the sixties or seventies). But I care about to get a
good quality player. And it is not the case actually with AP for peoples using
I am also sure at with the actual AP strenghts, if we can add a good sound
quality with the jack output, AP will be very appreciated by the professional
Another issue with this is (I just trust Fons on this because I don't know
at that tine) that it will be much easier to implement new sound formats
if AP's core is using floating point numbers.
In consequence, when you said lack of maintenance outside the core, I don't
agree because the core is still using a completely outdated integer sound
format. But it is normal when we see that the AlsaPlayer project was sleeping
under a few years. It is not a complain, just a fact.
> For the "file <filename>" instead of extension-based recognition: is
> this a real-life problem that you
> are addressing? (nb. This will even be a major performance hit for my
No, it is just a bug report that I transmit forward. We are using linux or
similar systems, and they usually don't rely on file extension (at least at
first). But it is not high on my priority list because if an user just rename
its file, it will work.
But, if someone is providing a patch, I will just be happy.
> Please, Dominique, do not misunderstand me, I am very glad that you
> stepped up and brought life
> into AP again, and, in turn, new contributions/contributors.
Well guys, I know that I am not a programmer, and you must be aware of that when
you are reading me. On the other side, I am an amateur musician and an engineer
in electronics, so I really understand what sound is about, and that both as
experience and as technology. And sound is first an experience, the technology
is only about mathematical approximations of the sound. The experience will
not be better as the sound approximation (but that's a complicated issue, as
example, in the real world, vacuum tube guitar amplifiers are better as solid
state ones when it is not the case on the paper sheet). And floating point
numbers will give AP's core access to a much better and modern mathematical
At the end, we can not get a better approximation as what the D/A converters in
the sound card can do. This is the job of the sound driver, but I don't want at
AP give a worst sound as what the sound card can do, and that even with high-end
As you said before, I don't want to reinvent the wheel. Fons said: "Also all
Linux audio processing code that you could re-use will be using floats."
Another issue you pointed out is bindings. I agree at more bindings will be a
good thing, but as I mostly use GUI softwares (my first good computer was an
Amiga, simple, easy and very efficient) when doing something else as system
administration, it will really be helpful if we can together get a list of
bindings to add.
Sorry if I forget something.
More information about the alsaplayer-devel