Subject: [ecasound] MISC: Of static & Timidity support & Info from MP3 header? & An idea
From: S. Massy (theanaloguekid@tak.net.dhis.org)
Date: Tue Oct 24 2000 - 22:46:15 EEST
Hi,
Here are a few topics that I gathered together, read on:
1) Of static
I spoke some time ago of the weird static blast heard whenever the
engine was started, or restarted, which only seemed present when OSS
(/dev/dsp) style was used, as opposed to ALSA devices. I had also sent
a follow-up saying that this problem seemed to be related (or at least
impacted) by the buffersize: where a smaller buffersize would increase
the problem and a larger one would diminish it. Kai had suggested that
the problem might be related with the use of oss-trigger, hereby
explaining why ecasound alone would be plagued with the problem. Well,
I got around to compiling a version of ecasound without oss trigger
yesterday (--disable-osstrigger) and the situation remained unchanged,
are there any other explanation possible then?
2) Timidity support:
I've noticed that, when working on a midi file fed to ecasound by
timidity under the shape of a raw file, it's not possible to move
around in the stream; (as with rw, fw and setpos) commands to move
will only restart the playing from the begining. When working with mp3
files, gotten from mpg123, it is possible to move around at will; so
is this a bug or simply a drawback to expect when using files directly
from timidity++?
3) Mp3 headers?
I remember reading on this list a while ago that ecasound would, from
now on, get the format informations straight from an mp3 file's
header, and thus would no longer need to have the format specified to
it via the -f option when reading mp3 files that wouldn't be stereo
with a samplerate of 44.1 KHz. Well, I've tried to play a mono mp3
stream some hours ago and I ended up with something very weird: a loud
buzz on one side with a distorted output on the other, played faster
than it should have been in spite of the fact that the file was really
a 44.1 KHz. It was fixed as soon as I put "-f:16,1,44100" in the
command-line though. I'm not quite sure that the whole purpose of
reading the headers was for automatically adjusting the format, but I
thought that if it was I should warn that it is broken now.
4) An idea
I like very much ecasound, it's capabilities and the fact that it is
fully "tamable" from the console; but there's something that I think
could make its text mode more useful: some interactive
display. Manipulation of soundfiles and the multiple parameters
related to sound usually yield instable results and much variation in
these very parameters; that's why I think some sort of real-time
display would be nice. Since the interactive mode is already using
ncurse maybe it could be possible to create a "sub-window" where these
parameters could be shown as they change; here are a few examples
where it could be useful to see the values of some parameters as they
change:
- The position in each files. (One does not need all the informations
given by "aio-status" each time.)
- The informations yielded by the "-ev" option. (Again, one does not
always need the complete table; especially if the purpose of the
application is to adjust the source's volume in real-time to avoid
clipping.)
- The status of the engine: running/stopped/finished (especially when
doing none real-time stuff this time.)
There are many more and I think it could make ecasound's text mode all
the more useful and pleasing to use. One thing though, this "feature"
would have to be toggled on or off because it could be hindering in
certain situation. Anyway, I don't know what others think of this idea
or if it would be too troublesome to implement to begin with...
Well, sorry for keeping you so long, that's what happen when you try
to kill too many birds with a single stone. :)
Regards,
S. Massy
-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.
This archive was generated by hypermail 2b28 : Tue Oct 24 2000 - 22:54:59 EEST