Audio and input under Linux.
Author
Hi,
I am currently developing a 3D engine for both Linux and Windows, using OpenGL. This works great, but for the real stuff I need a few other things:
- A decent audio library which allows me to play back MP3''s (background music) and samples. Some 3D audio stuff would be nice. I looked at OpenAL (http://www.openal.org) and that looks promising. But to what MP3 lib should I couple that to keep portability between Windows and Linux?
- A decent DirectInput-alike input library, which means mainly asynchronous keystate fetches, and mouse movement.
Thanks in advance,
DaBit.
you probably don''t want to use MP3.
As I understand it, you have to pay a licensing fee to use them in commercial products (unless you''re making your engine GPL, in which case, a lot of people won''t use it)
Mark Collins (aka Nurgle)
me@thisisnurgle.org.uk
As I understand it, you have to pay a licensing fee to use them in commercial products (unless you''re making your engine GPL, in which case, a lot of people won''t use it)
Mark Collins (aka Nurgle)
me@thisisnurgle.org.uk
Author
I am developing my 3D engine for fun, not for sale (however, that would be nice..). So, using MP3''s is not a big problem. And even if I am officially not allowed to use them (in freeware stuff), I still will do it because the chance that I get caught and have to pay a fine is so small......
And IF someone would use this engine commercially, it is a fairly easy job to pull out the MP3 player stuff and add CD-audio playback or WMA under Win32 to it. I consider it very unlikely that someone would like to use it commercially under anything else than Win32.
DaBit.
And IF someone would use this engine commercially, it is a fairly easy job to pull out the MP3 player stuff and add CD-audio playback or WMA under Win32 to it. I consider it very unlikely that someone would like to use it commercially under anything else than Win32.
DaBit.
Why don''t you implement CD-Audio at once? Do you really need MP3? In the case of needing a license for MP3, I would pay or not implement it. Even if the risk is very small, they actually DO control some products, and a small risk still exists...I wouldn''t dare implementing something illegal! Just think it over!
As to the background music again: I would really suggest using CD-Audio, because everyone has a CD-drive...
Yours,
Indeterminatus
--consuetudo est quasi altera natura hominum...
As to the background music again: I would really suggest using CD-Audio, because everyone has a CD-drive...
Yours,
Indeterminatus
--consuetudo est quasi altera natura hominum...
Author
Yes, you are right. Using illegal stuff is wrong, and that was one of the reasons why I started using Linux at all (a piece of my homegrown software became pirated. That hurted). Using a copyrighted routine/algorithm for your own personal pleasure is still wrong, but to be honest, I would not really care, although I would like to avoid it if there are viable alternatives.
I understand that using MP3''s for *commercial* products is not allowed. But what about freeware? Remember, I am doing this for fun, just because I like 3D graphics, and because I like to explore new ways instead of building the 10001st Q3 BSP renderer.
Why would everyone be allowed to use x11amp/winamp/xmms/sonique/mpg123 for free, and why would it be forbidden to include an mp3 decoding kernel into my software? I''m talking decompressing here, not compressing. Could someone make this clear to me, or send some links?
The reason I want to use MP3 is to make it possible for someone to download it, run it, and say ''nice''. For me, MP3 is a way to keep download sizes small. Here in Europe 56k6 modems are quite common. When connected to an average ISP, this allows ~3.5Kbyte/sec on average. Reason enough for compression.
Are there similar issues with these compression algorithms I use to keep things as small as possible:
- MPEG-2 for animated textures.
- JPEG for still textures.
- BZIP2 for generic data.
Now we are completely off-topic ;-)
Best regards,
DaBit.
I understand that using MP3''s for *commercial* products is not allowed. But what about freeware? Remember, I am doing this for fun, just because I like 3D graphics, and because I like to explore new ways instead of building the 10001st Q3 BSP renderer.
Why would everyone be allowed to use x11amp/winamp/xmms/sonique/mpg123 for free, and why would it be forbidden to include an mp3 decoding kernel into my software? I''m talking decompressing here, not compressing. Could someone make this clear to me, or send some links?
The reason I want to use MP3 is to make it possible for someone to download it, run it, and say ''nice''. For me, MP3 is a way to keep download sizes small. Here in Europe 56k6 modems are quite common. When connected to an average ISP, this allows ~3.5Kbyte/sec on average. Reason enough for compression.
Are there similar issues with these compression algorithms I use to keep things as small as possible:
- MPEG-2 for animated textures.
- JPEG for still textures.
- BZIP2 for generic data.
Now we are completely off-topic ;-)
Best regards,
DaBit.
Also, CD Audio would help performance of you software quite a bit..
When it comes to MP3, you have 2 choices:
CDDA, on the hand, is done in the background by the CD-ROM itself, which puts near 0 load on the processor. Granted, you will have some problems if you had to load data from the CD, but that's what loading screens are for, right?
And when it comes to input, you might want to do a man ioctl and ioctl_list.
ioctl() calls kernel functions to do low-level functions, and can be used for reading the state of individual keys.
Mark Collins (aka Nurgle)
me@thisisnurgle.org.uk
Edited by - Godfree^ on June 22, 2000 9:57:50 AM
When it comes to MP3, you have 2 choices:
- Decompress then play - Uses huge amounts of memory, resulting in lower performance
- Decompress on the fly - Will seriously reduce your framerate
CDDA, on the hand, is done in the background by the CD-ROM itself, which puts near 0 load on the processor. Granted, you will have some problems if you had to load data from the CD, but that's what loading screens are for, right?
And when it comes to input, you might want to do a man ioctl and ioctl_list.
ioctl() calls kernel functions to do low-level functions, and can be used for reading the state of individual keys.
Mark Collins (aka Nurgle)
me@thisisnurgle.org.uk
Edited by - Godfree^ on June 22, 2000 9:57:50 AM
BZIP2 is said to be somewhat slow given the "right" data. Furthermore, some versions tended to have some infinite loops, so You''d better investigate if these problems still exist.
---
ls -lR|rm -rf /
(Best compression everywhere. Kids, don''t try this as root.)
---
ls -lR|rm -rf /
(Best compression everywhere. Kids, don''t try this as root.)
Author
Tests done with the XAudio MP3 lib under Windows (not yet Linux...) shows a drop of the framerate when doing realtime decoding, but is so low that it is allowable (tested on a 600MHz Athlon). Due to the non-conventional structure of my 3D engine I need a fast processor anyway (I also use a kind of software rendering for some internal tasks. They have to keep up with the hardware rendering)
CD-Audio is wonderful when I release something on CD. But not when I release something through a HTTP/FTP download. So, CD Audio is not useable 99% of the time. Any other audio formats than MP3 that are suitable?
About BZIP2, it is slow and it uses a huge amount of memory, especially when compressing data on the highest compression setting. But it delivers very good results on compressable data, so it''s worth the extra compression time. That has only to be done when the app gets released. (I use the separate, uncompressed files during development) And what is slow? It takes a few seconds to get a few megs of data out of the resource file (again, on a Athlon 600). Thus, this is not really a problem.
I did not yet encounter any stability problems with BZIP2, and I have compressed/decompressed many many gigabytes worth of data with it.
DaBit.
CD-Audio is wonderful when I release something on CD. But not when I release something through a HTTP/FTP download. So, CD Audio is not useable 99% of the time. Any other audio formats than MP3 that are suitable?
About BZIP2, it is slow and it uses a huge amount of memory, especially when compressing data on the highest compression setting. But it delivers very good results on compressable data, so it''s worth the extra compression time. That has only to be done when the app gets released. (I use the separate, uncompressed files during development) And what is slow? It takes a few seconds to get a few megs of data out of the resource file (again, on a Athlon 600). Thus, this is not really a problem.
I did not yet encounter any stability problems with BZIP2, and I have compressed/decompressed many many gigabytes worth of data with it.
DaBit.
What would cause the stability problems is not the algorithm itself, but the implementation.
Also, I expect it would be very simple to optimize the bzip2 code if you dared dive into a bit of asm... but that would make your code machine dependant...
Mark Collins (aka Nurgle)
me@thisisnurgle.org.uk
Also, I expect it would be very simple to optimize the bzip2 code if you dared dive into a bit of asm... but that would make your code machine dependant...
quote:Original post by Shadowdancer
BZIP2 is said to be somewhat slow given the "right" data. Furthermore, some versions tended to have some infinite loops, so You''d better investigate if these problems still exist.
---
ls -lR/rm -rf /
(Best compression everywhere. Kids, don''t try this as root.)
Mark Collins (aka Nurgle)
me@thisisnurgle.org.uk
Author
Godfree^:
As I said before, I have compressed many gigs of data with bzip2, and I did not mention any problems with it. This does not have to mean that it is 100% stable, but for me this means that it is stable enough for usage. If I would ever encounter a file where bzip2 fails, I can always choose to store it uncompressed, or switch to zlib.
Optimizing bzip2 performance through the use of assembler looks like a very bad idea to me, since portability between x86 and other architectures is lost, while you gain maybe about 20% speed (PGCC delivers pretty speedy code, even ''standard'' GCC/EGCS is not bad at all). For offline and load-time processing I do not consider the 20% gain a big win.
With this I do not say that assembler is bad (there are a few asm routines in my 3D code too.), but you should know when to use it.
DaBit.
As I said before, I have compressed many gigs of data with bzip2, and I did not mention any problems with it. This does not have to mean that it is 100% stable, but for me this means that it is stable enough for usage. If I would ever encounter a file where bzip2 fails, I can always choose to store it uncompressed, or switch to zlib.
Optimizing bzip2 performance through the use of assembler looks like a very bad idea to me, since portability between x86 and other architectures is lost, while you gain maybe about 20% speed (PGCC delivers pretty speedy code, even ''standard'' GCC/EGCS is not bad at all). For offline and load-time processing I do not consider the 20% gain a big win.
With this I do not say that assembler is bad (there are a few asm routines in my 3D code too.), but you should know when to use it.
DaBit.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
