BpmDj: Frequently Asked Questions

Q: Latency is too high/cue-positions are wrong

Okay, 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 decreasinbg 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 (please note, that all extensions must have 3 characters !)
  • Find a suitable command line utility to decode your ...xyz song. Good examples of such a tools are ogg123 and mpg123
  • Extend the glue-bpmraw 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.van.belle@vub.ac.be)
  • 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 wan'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 solve the problem.
  • Q: It Does not Compile !!!

    Yes, before you compile the program, you need to setup the defines file. This file must  point to a compatioble 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.1 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: 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 uyse the meta-information that can be stored in an mp3-file.

    Copyright (c) Werner Van Belle December 2001
    e-mail: werner.van.belle@vub.ac.be
    Tel: +32 486 68 84 48; Fax: +32 2 629 35 25
    http://bpmdj.sourceforge.net/