BpmDj:
Frequently
Asked Questions
Q: It says something about 'enabled capacities' etc...
(and does not work)
bpmplay relies on a variety of
programs to decode files. To decide which program is used to decode a
specific file, every player has a list of capacities (which is the set
of programs that is available on that machine). Since not always, all
available capacities should be used, or since sometimes a certain
capacity _needs_ to be available (for instance in distributed
environments, relying on a variety of distribution that are upgraded
automatically), the player allows the use to select which capacities
are and are not to be used. This is done in the setup box of the
bpmplayer. If the enabled capacities do not match the available
capacities then it will not start and give an error. To fix the problem
- either install the missing software
- disable the use of a specific piece of missing software. This can
be done by clicking on the red colored capacities. (see picture below)
Q: bpmdj does not start bpmplay
The
console error is something like 'Debug: sh bpmplay could not start
This
can happen when you use unbuntu edge 6.x with a dash shell. Replace
dash with bash and it will work. Or make sure that /bin/sh points to
bash and not dash.
Q: It does not
compile
!!!
Before you compile the program, you
need to setup the
defines file. This file must point to a compatible set of
QT libraries, headers and binaries. That is to say. If you point to a
moc
compiler of version 2.4 and include the headers of 3.3 then compilation
will not work. When compiling also make sure that you are not using QT
3.0.5. Accoring to some people this will not work.
A common mistake seems to
be a mismatch
between QT-multithreaded headers and a standard qt-library or
vice-versa.
If you get languageChanged link errors, try to use -lqt-mt as a library
(otherwise try to use -lqt)
Q: My soundcard
doesn't work
First you need to figure out which
drivers are available for you soundcard. Sometimes there exists OSS and
ALSA modules, sometimes only one of both. Certain audio cards have
extremely poor OSS drivers, others have
extremely poor ALSA drivers. Choose the driver that works best for you.
Once you have selected the drivers you want to use, make sure you can
play both cards at the same time (with something like xmms, alsaplay,
whatever player you want to use that normally works).
Second, once you have decided which
drivers you will use, you need to
inform the bpmdj software of this. This is done in
Programs|Preferences. Select the first player-command and click on
'create'. Select the correct options for your card and try to start it.
Do the same with the monitor playcommand.
Third: if every player can play solo, make sure to tune the latencies
to a correct measure such that they can play together. This shouln't be
too difficult though.
Warning:
if you are using an ALSA module that has OSS support enabled, don't
bother with trying to use the OSS module of bpmplay, this will not
work correctly !
Q: Latency is
too high/cue-positions
are wrong
This is especially a problem of the
OSS-drivers.
The problem with latency is that
the problem contatins three subproblems.
The first problem is the
actual playing
latency (or
how long can the device play without new input. This is important
because
it defines how fast it responds to nudge-commands. If you have a
playing
latency of 1 second, the player will wait with you nudge
commands for oine second. This is of
course
barely useful.
The second problem is the problem
of
knowing
what the DSP device is currently playing.
This is especially necessary to know at what time you marked a cue.
The third problem is how
long the device will stay playing after
pressing
'stop'.
The Latency
Normally, one
can modify the latency of a sound
device
by tuning some parameters. However, different pieces of hardware and
different
implementations of OSS-drivers will exhibit different behviour when
tuning
these parameters. The result of this is that it is, from a programmers
point of view, very difficult to implement a player that plays at a
given
latency. Therefore, we have offered the possibility to set the
latency
to a required argument., with the -L
switch. However, instead of believing that the OSS driver sits the
right
way on the toilet seat, I check the parameters offered by the drivers.
This information should help you in fixing your latency-problem. To
reduce
the stop-time when pressing stop you can increase the number of
fragments
used. This can be done with the --fragments
(-F) option.
Cue-positions
The second
problem: that of the correct
positiong
of a cue is difficult to solve. Normally a program fills a buffer and
then
tells the soundcard to play that buffer. Determining which samples the
soundcard is playing is very difficult, especially when the buffer is
being
filled semi-continuously. Theoretically, OSS drivers have a feature
that
enables you to retrieve the current playing position. However, this
information
is often wrong because the software or the hardware are unable to offer
the playing position up to a reasonable precission. A second reason why
this reported position is often wrong is that the play-counter of DSP's
does not take into account underruns. An underrun is a situation where
there is not enough data in the playing buffer because the application
program did not supply any extra data. This especially occurs when the
latency has been set very low. In this situations the cue-position will
drift enormously.
In newer
versions of the OSS drivers there
exists
the possibility to retrieve the number of underruns. Nevertheles, this
feature is not yet widely known too many kernels, therefore this
feature
has not yet been enabled. Nevertheless,
in the meantime to solve the
wrong
cue-positioning:
By decreasing the latency,
the accuracy of
the cue-positions
will increase
Make sure the the latency is high
enough to
avoid
many underruns
If your DSP device or the OSS -driver
fucks
up and
reports completely wrong playing-positions start the player with --nolatencyaccounting
Q: How about
supporting
other file-formats ?
This is no
problem. Let's assume you want to add '.xyz'
files
Find a suitable command line utility to decode your
...xyz song. Good
examples
of such a tools are ogg123 and mpg123, mplayer and so on..
Extend the bpmdj-raw script to include your file type. Make
sure to
export
the file to the current directory with the name ...xyz.raw
If you are able to play files, send me your extended script.
(werner@yellowcouch.org)
To make the file selector recognize your files you need to
modify the SONG_EXT variable in scripts.h
modify the goodExtension(...) function in dirscanner.cpp
Q: Why don't you use
a real database engine ?
There are
a number of reasons for this:
Starting users won't to be able to use the program
quickly, without the
need to install and set up access right to something like mySql or
Postgress
SQL.
A Database would not increase the speed by which the program
starts up
because when it starts it automatically does a PCA analysis of all songs,
hence all data needs to be investigated. No database can solve this
problem.
At runtime a _real_ database engine would not help either
because when
a songs becomes the mainsong, again all songs must be
investigated
to see how large the color distance is. This data must be computed and
cannot be stored automatically, therefore, also here no database can
speed up the program.
Q: Why these
seperate
.idx files ?
Because,
often the file that contains the music data (the
mp3)
cannot modified because
The songs are on a shared
medium on which
you have
no write-access
The songs are on a CDROM
The songs themselve are not mp3-encoded
and
do not
offer any additional meta-information.
These are the three reasons why we don't use the meta-information that
can be stored in an mp3-file.
Q: Is There a
Windows
Version Available ?
No. If you
are willing to spend time on helping to port it
to windows let met know.
e-mail: werner@yellowcouch.org
