A: Some client can make use of several devices at once. These clients take several devices as arguments:
gdam-launcher --device /dev/dsp1 --device /dev/dsp |
The deviceswitcher component allows gui components to be switched between the first and second devices. If you are using more than two devices, you'll have to modify deviceswitcher*.xml to contain more device selection buttons.
Additionally you may have to add lines to your server.config file:
Device "oss" "/dev/dsp8" |
where /dev/dsp8 is the device you are trying to use.
A: With only one sound device, a user has no ability to cue a new track. (ie listen to something which isn't played to the entire room.) In this situation, all sound sources are mixed into a single stream which goes to the device. Continuous mixing can only be done using the automated beatmatching system, which requires knowledge about each song used.
With two sound devices, there are different ways to mix. The first method is to mix the room's sound on one device, and use the other channel for previewing new tracks, setting up loops and sequences, etc. Streams are output to only one device, but which device can be switched on the fly. This allows the user to preview a song playing alongside the current mix, then mute it, switch devices, and fade it into the main mix. However, be aware that sound output by the two sound cards will most likely be slightly out of synch. Thus, one will likely use the automatic beatmatching after switching devices.
An alternate method is use an external, physical mixer to crossfade between two sound cards. One stream is assigned to each device, and new tracks are cued by making one channel audible only on the mixers' headphone output. This allows the user to adjust the speed and position of each stream until they play in synch, and then bring up the room volume of the new channel. Thus, songs can be beatmatched by hand, as with a standard dj turntable setup. A benefit of this method is that beat info isn't required to get a clean mix. If beatinfo is know, it can be used to automatically beatmatch songs across devices. However, the sound output by the two sound cards will likely be slightly out of synch, so the user will most likely need to nudge it slightly for perfect alignment.
There is a further phase of device usage which we are working towards. In this next stage, any stream can be output to multiple devices, with different volumes. This will allow the user to preview a copy of the room mix with a new stream audible only to him. This full cueing capability will allow beatmatching by hand without an external mixer.
A: In short, beat synching works by relying on information about songs read from a database to automatically match the tempo and phase of multiple streams. This information must be determined by a person at some point, probably using tools provided with gdam. Beat synching is optional, to provide users instant, perfect control over their favorite songs. see doc/beatmatching.txt for more information.
A: If the labels are drawing over themselves without erasing the old text, or tooltips are popping up without text, it is probably because you're using an early, buggy gtk themes package. Upgrade to the latest gtk packages, see gdam.org for details.
A: In unix, every file and every process is owned by a "user". Also, every file is owned by a "group" and every process can be a member of a number of groups. You can use the "groups" command to see which groups you are a member of.
If you are in the same group or user as a file, you can change or destroy that file. If you are in the same group as a process, you can `kill' that process.
In order to be more secure, by default, GDAM "drops privileges" and runs as user "nobody" and group "audio".
Your system is complaining because you don't have a group "audio". It is recommended you add one.
To add the group run either (as root):
groupadd audio |
addgroup audio |
If you do not have either of these commands you should consult your system documentation (you may have to edit /etc/group manually).
You should probably add yourself to group audio:
usermod -G audio your_username |
(You may have to modify /etc/group manually if you don't have that program).
Finally, make the sound devices accessible to group audio:
chgrp audio /dev/dsp*
chmod g+rw /dev/dsp*
|
This should help gdam run securely, even if you start it as root.
A: Try running gdam-launcher with the "--define unstable" flag. Features which are under development, or have been found to be buggy, are marked unstable and require this flag to be available. Please note that if you define "unstable" at startup, gdam-launcher may make horrid sounds or seg fault.
A: GDAM opens each sound device with an output buffer. The larger the output buffer, the greater the latency between pressing a button and hearing the result. A smaller output buffer gives a more responive system, but is more likely to suffer dropouts when the processor is busy. The goal is to find a buffer size small enough to feel responsive, but large enough to avoid dropouts under normal use.
The server.config file lists the amount of buffer each sound device will be opened with. The amount is given as a number of memory fragments, and the log of the fragment size. Three fragments of base twelve corresponds to 70 milliseconds:
Message: Set soundcard fragments: 3 frags of 4096 bytes; 0.070s |
If the server is feeding several sound cards, it may have trouble keeping up with small buffers.
Running the server as root allows it to run at a high priority, decreasing the likelihood of dropouts. If you don't run the server as root, use a root shell to nice it to -20. This will help prevent other programs from competing for processor time.
A few boot-time options and system tunings can be helpful. Try passing your kernel the 'no-hlt' option at boot. Use hdparm to tune your hard drives, enabling 32-bit transfers and turning on DMA.
Certain hardware can occupy the kernel for long amounts of time, making low-latency sound impossible. When i had an old pci video card, i had to keep the soundcard output buffer at 140ms or greater to avoid dropouts. After replacing it with a new agp video card, i was able to reduce the output buffer to 17ms. I've read that some ps2 mice can occupy the kernel for up to 50ms, but mine doesn't seem to do so.
Low-latency advocates have developed patches for the linux kernel designed to improve low-latency performance. If you are using a 2.2 kernel, try patching with mingo's low-latency patches. If you are using a 2.4 test kernel, try looking for the appropriate patches on the linux-kernel mailing list.
For more information see the low latency mini-howto and the linux audio quality howto.
A: With the standard kernel code, this can be tricky. You'll probably compile sound support as modules, and insert the cards one at a time with any necessary parameters.
With the commercial OSS drivers from 4front technology, I had no problem getting several cards to work at once. Their configuration utility autodetected and installed all three of my sound cards. Many cheap and a few professional cards are supported. A basic license costs $20, certain cards require more expensive options.
The ALSA project has developed a free set of drivers meant as a powerful alternative to the standard kernel drivers. Many cards are supported, and the system is designed to support multiple cards without conflict.
An alternative to multiple sound cards is a multi-channel sound card. I get great performance from my Trident 4DWave sound card, which features seperate front and rear stereo outputs. A benefit to a card like this is that the timing of two channels, and the devices which feed them, is identical... they will not drift or be read from at different times. One aspect of using this card is that i have to adjust the front and rear volumes of my sound devices by hand each time i restart the gdam server.
A: Those with SoundBlaster Live or Trident 4DWave cards can use your rear output for an independent cue channel. Currently This is only possible with ALSA drivers. See "Supporting Four-Channel Soundcards In GDAM" in the user manual.