[Home]
[News and ChangeLog]
[Documentation and Wikis]
[Contact]
[Contributing]
[Downloads]
[Applications]
[FAQ]
[Comparison]
[Tantalos]
[RoarAudio PlayList Daemon]
[RoaringBox]
[RAUM]
The most simple and normaly working way is to use tool 'roarify':
$ roarify myapp
All settings like server address should be configurable via you application as normal.
The most simple and normaly working way is to use tool 'roarify':
$ roarify myplayer
All settings like server address should be configurable via you application as normal.
Yes. libroaross provides a very good compatibilty library. It works with most applications very well.
You can use it by using roarify the normal way:
$ roarify MyOSSApplication
As OSS does not have any equvalent of a server you need to set the server name using $ROAR_SERVER
or set it with --server like this if you want to connect to a remote server:
$ roarify --server MyServer MyOSSApplication
First they check they check the following sources for server addresses:
Now we may have a address to connect to. We try to connect to it and in case it fails the connection fails. In case we do not have an address yet the library will try the following locations. The connection only fails in case no connection to none of them could be established:
OpenSLP lookup can in addition be forced by providing server name '+slp'. Compatibility layers may add additional sources for server names.
To connect to a server on the network you can simply set the server using the config dialogs of the application you use or set the environment variable $ROAR_SERVER.
You may want to consider to use OpenSLP based auto locating of the server.
To enable autolcating of servers on your network you should install an OpenSLP server on at least one of your machines. Next you simply need to provide --slp to your roard so it annouce itself. Ensure you set a hostname or address reachable from the network with --bind. Your operating system may provide a nice way to do that. In addition you can set a location for the server using --location.
The clients will automaticly autolocate the sound server via OpenSLP in case no other server is configured. You can set the server address to '+slp' to force OpenSLP based auto location of the sound server.
In case you chroot roard you do not need to care much about it as long as you use --chroot. roard does everything befor doing the chroot needing a complet filesystem. So it is save to chroot into a completly empty directory. However it is unabled to delete it's sockets and pidfiles in case they are located outside the chrooted directory.
In case you chroot your clients you need to ensure they can access the socket. You can use TCP oder DECnet or set the location of the UNIX socket roard uses to be within the chroot environment. You can easly add multiple sockets to roard using --new-sock.
Thanks for intrested in helping! In case you want to help the project the best way is to ask on the mailing list or IRC (see Contact) about currently open jobs.
RoarAudio uses a IO driven communication model so there are no callbacks for streams and such.
We do this to avoid using threads and OS depending features. Threads make software more complex and complicate to debug and analyze. We think that using Threads implies a big risk of writing buggy, broken and security problematic software. Because of this RoarAudio is completely 'classical IO' driven.
If you want callbacks in your application you may just want to set up a thread which calls a callback as soon as a read or write finished.
Bugs are currently best reported to our mailing list (see the Contact page for more details).
If you report a bug please include at minimum those informations: Version of RoarAudio and involved tools (players,...), Operating System name and version (uname -a on most systems), a bref description of the bug and a bref description how to reproduce it. Depending on the bug information like the used compiler (and version), version of make and version of linked librarys may be helpful.
Floating point numbers are normally implementation depended. This means how they are represented in the memory depends mostly on the CPU used. Different CPUs use different representations.
This means that floats are normally not portable. Because of this they can not be send unchanged over the network. Network support is a primary goal of RoarAudio.
There is IEEE 754, a standard on how to represent floats in a portable way. However beside the fact that converting takes normally much more time then converting to/form integers and is implementation depending (one needs to write such an converter code for each and every CPU out there) it is not supported by RoarAudio. This is also why most IEEE 754 implementations are broken. Do not trust random applications telling they would do IEEE 754!
The RoarAudio Playlist Daemon is a player backend that can handle playlist for the player, a queue of currently played files and do the actual playback. As it is based on RoarAudio's DSTR it can handle internet streams, encryption, compression, etc as well as normal files.
RoarAudio is a cross-platform sound system for both, home and professional use. It can be used to mix audio for output on a single-stream soundcard or to play audio over the network.
Romie is a Web based Player based on RoarAudio. It can play music on some kind of music server an is controled via a webinterface.
Tantalos is a protocol to auto locate content such as audio files on your local network. It was designed to help players to share playlists as they do no longer need to care about filenames. Tantalos is auto locating the files for them and downloads them on the fly.
In addition Tantalos can be used to search for files by title, artist and some other meta data.
"RoN" stands for "Roar over Network". A RoN Application is a application that allows the user to send (mainly) speech over the network in real time. The diffrence to VoIP applications is that a RoN Application's goal is to not limit the user to Voice nor IP.
See What is RoarAudio Playlist Daemon.
µRoar is a minimalistic library which enables a program to open a stream and send or receive data from/to the RoarAudio Sound Server. This library in contrast to libroar (RoarAudio's main library) allows to be linked with non-free and non-GPLed programs.
µRoarD is a minimalist sound daemon supporting the RoarAudio Protocol. It does not have much features but is very small. The exackt set of features can be controled at runtime by editing a header file.
Yes. RoarAudio works under most modern Operating Systems ver well. This includes all POSIX like systems including Linux, OpenBSD, NetBSD and many more. There are also Ports to other Operating Systems.
Yes. RoarAudio is designed to run on as many hardware as possible. It supports from 8 bit Microconterollers up to big 64 bit servers. Please contact us in case you have a real exotic architecture it does not run at.
There is a experimental port for win32. This port include working minimalistic RoarAudio librarys, basic tools and roard. The transport layer support is limited to IPv4 on win32 as win32 does not support any other types of sockets.
A stream is an object representing (flowing) (audio) data in the server. In case an application want's to send or recive some (audio) data to/from the server it needs to open a stream via the controll connection. After it created the stream it can send/read the data to/from that stream.
An execed stream is a stream which uses the control connection as data connection after the stream has been set up. This is usfull for small applications which will not update any (meta)data while the stream is running to save resources.
This is also the most portable type of stream and works best with NAT firewalls.
The most easy way to play back a file using RoarAudio is by using 'roarcatplay' like this:
$ roarcatplay somefile.ext
roarcatplay can play everything roard has support for.
To record a file you can use 'roarmon'. It can write files in all formates supported by roard. You may need to set the --codec parameter to the format you want to use.
Examples:
$ roarmon --codec ogg_vorbis output.ogg
$ roarmon --codec riff_wave output.wav
To record the output of some other stream you need to use --thru like this:
$ roarmon --thru --rel-id stream-id output.ext
With stream-id being the ID of the stream you want to monitor.
Powered by Fellig.org, Vim and Freedom.