Linux/FreeBSD/Mac OS X etc sound
Moderator: ZSNES Mods
-
- Locksmith of Hyrule
- Posts: 3634
- Joined: Sun Aug 08, 2004 7:49 am
- Location: 255.255.255.255
- Contact:
If you mean in 1.42 official, no, you will need to download the .c files and overwrite, then compile.
<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
NSRT here.
NSRT here.
-
- Rookie
- Posts: 15
- Joined: Mon Jan 09, 2006 2:22 pm
Agreed. ESD is awful! Don't forget that it locks other applications out of using OSS too! alsa-dmix rocks (on my laptop anyway, my desktop has an audigy2 so alsa with hardware mixing works like a charm)Aerdan wrote:orly
I have *never* had extra line noise with dmix, I have *never* had to kill someone's zombied daemon with dmix.
In my view, it is the best option for software mixing available at this time.
Anyway, my vote goes to ALSA. Quick question, will zsnes try to use ALSA first by default or OSS?
And behind me is
the Whole Hole
It consumes
anything.
--Yomi (Terranigma)
the Whole Hole
It consumes
anything.
--Yomi (Terranigma)
Someone has sent me OpenAL code for people to test.
http://zsnes.game-host.org/~pagefault/sdllink_openal.c
You must add -lopenal and -lacl to the Makefile. Post all feedback here.
http://zsnes.game-host.org/~pagefault/sdllink_openal.c
You must add -lopenal and -lacl to the Makefile. Post all feedback here.
-
- ZSNES Developer
- Posts: 3904
- Joined: Tue Jul 27, 2004 10:54 pm
- Location: Solar powered park bench
- Contact:
The code doesn't seem to be using Bisqwit's algorithm for accurate sample amount per frame, in which case I don't see the point.pagefault wrote:Someone has sent me OpenAL code for people to test.
http://zsnes.game-host.org/~pagefault/sdllink_openal.c
You must add -lopenal and -lacl to the Makefile. Post all feedback here.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
_____________
Insane Coding
Im the one who wrote the code. I don't know a whole lot about sound programming. I just threw that together to fix the stalling bug and get halfway decent sound. I'm not sure what Bisqwit's algorithm is or how to implement it, so if someone what to explain it or tell me where I can find out more about it then I can try to put it in. As for now it should work decently on most computers, though I haven't tried it on anything but my desktop.The code doesn't seem to be using Bisqwit's algorithm for accurate sample amount per frame, in which case I don't see the point.
-
- ZSNES Developer
- Posts: 3904
- Joined: Tue Jul 27, 2004 10:54 pm
- Location: Solar powered park bench
- Contact:
Look at the wav output in zmovie.cYohumbus wrote:Im the one who wrote the code. I don't know a whole lot about sound programming. I just threw that together to fix the stalling bug and get halfway decent sound. I'm not sure what Bisqwit's algorithm is or how to implement it, so if someone what to explain it or tell me where I can find out more about it then I can try to put it in. As for now it should work decently on most computers, though I haven't tried it on anything but my desktop.The code doesn't seem to be using Bisqwit's algorithm for accurate sample amount per frame, in which case I don't see the point.
Or more confusing but here http://zsnes.game-host.org/~pagefault/synctest.c
To get an idea what the trick is to get the correct amount of samples per frame.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
_____________
Insane Coding
alright... I looked over the code and implemented Bisqwit's algorithm into it and it works pretty well now.
if you want to check it out it is at
http://www.geocities.com/yohumbus/sdllink.c
one thing I did though that I am unsure of is that if the sample size is over 1280, instead of having one buffer of 1280 and a second of the remainder like how the OSS code works I just have the code fill up 2 buffers with half the amount for a total of the correct sample size.. I was curious if this method works the same because it sound fine to me (and I dont fully understand how Bisqwit's algorithm works).
One other thing though... I was looking at the OSS code and I think I know why it wont work for some people...
the lines
while (result >= lastresult || result == -1)
{
ioctl(fdAudio, SNDCTL_DSP_GETOPTR, &result);
}
are used to keep the buffer small and lower the latency of the sound by preventing buffer overruns (I think); however, SNDCTL_DSP_GETOPTR returns the amount of time in samples that the next data put into the card will wait before being played... this includes not only the samples already in the buffer (which the while statement accounts for) but also the latency of the sound card. This means that people such as myself with crappy high latency sound cards keep getting buffer underruns because of this while statement.
My guess is that if the while loop could compare result against lastresult and the card latency then the sound would be decent. I just dont know how to get a good estimate of the sound latency.. perhaps calling
ioctl(fdAudio, SNDCTL_DSP_GETOPTR, &result);
while no sound is in the buffer would work, but it probably wouldn't be consistent.
anyway I tested this theory by removing the while statement and lo and behold I got better sound then I had been getting with the OSS code before.
if you want to check it out it is at
http://www.geocities.com/yohumbus/sdllink.c
one thing I did though that I am unsure of is that if the sample size is over 1280, instead of having one buffer of 1280 and a second of the remainder like how the OSS code works I just have the code fill up 2 buffers with half the amount for a total of the correct sample size.. I was curious if this method works the same because it sound fine to me (and I dont fully understand how Bisqwit's algorithm works).
One other thing though... I was looking at the OSS code and I think I know why it wont work for some people...
the lines
while (result >= lastresult || result == -1)
{
ioctl(fdAudio, SNDCTL_DSP_GETOPTR, &result);
}
are used to keep the buffer small and lower the latency of the sound by preventing buffer overruns (I think); however, SNDCTL_DSP_GETOPTR returns the amount of time in samples that the next data put into the card will wait before being played... this includes not only the samples already in the buffer (which the while statement accounts for) but also the latency of the sound card. This means that people such as myself with crappy high latency sound cards keep getting buffer underruns because of this while statement.
My guess is that if the while loop could compare result against lastresult and the card latency then the sound would be decent. I just dont know how to get a good estimate of the sound latency.. perhaps calling
ioctl(fdAudio, SNDCTL_DSP_GETOPTR, &result);
while no sound is in the buffer would work, but it probably wouldn't be consistent.
anyway I tested this theory by removing the while statement and lo and behold I got better sound then I had been getting with the OSS code before.
-
- ZSNES Developer
- Posts: 3904
- Joined: Tue Jul 27, 2004 10:54 pm
- Location: Solar powered park bench
- Contact:
Thanks I'll try to test it out.Yohumbus wrote:alright... I looked over the code and implemented Bisqwit's algorithm into it and it works pretty well now.
I looked at the code, and it worries me.Yohumbus wrote: one thing I did though that I am unsure of is that if the sample size is over 1280, instead of having one buffer of 1280 and a second of the remainder like how the OSS code works I just have the code fill up 2 buffers with half the amount for a total of the correct sample size.. I was curious if this method works the same because it sound fine to me (and I dont fully understand how Bisqwit's algorithm works).
You must generate the correct amount of samples per second to not kill the audio, and at the same time if you're in stereo mode you're only allowed to generate an even amount of samples per frame.
Just deviding in half won't work if the original was mono and odd, or it's stereo and output is odd for each (in which case you get a crash). And if you have one more or less samples generated per frame, you kill the audio sync.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
_____________
Insane Coding
yeah... I did make sure to make the values even but in that case the audio sync will be killed. Thats why I asked b/c I didn't know if there would be any sorts of problems doing it the way I am.. I dont notice any syncing problems though... I didn't even notice any while I wasn't using Bisqwit's algo either. Im working on it though... the fix should solve all the problems.
-
- ZSNES Developer
- Posts: 3904
- Joined: Tue Jul 27, 2004 10:54 pm
- Location: Solar powered park bench
- Contact:
You need a really sensitive game, such as Tale of Phantasia's intro to notice the difference with samples being off by just a few.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
_____________
Insane Coding
Alright... I've fixed it to the best I could. In Tales I still get a couple of screeches (not sure if that is the indication for being out of sync). I have made sure that every sample that Bisqwit's algo calls for is read though. I have also added in a bit to fill the first three uses of the buffers with blanks to prevent too many samples being processed in the first frame after a sound init. Now the first frame should guaranteed one frame's worth of sound buffering from the game. In any case the new code is at the old location.
http://www.geocities.com/yohumbus/sdllink.c
http://www.geocities.com/yohumbus/sdllink.c
-
- ZSNES Developer
- Posts: 3904
- Joined: Tue Jul 27, 2004 10:54 pm
- Location: Solar powered park bench
- Contact:
Yes that pretty much is a good indication of bad sound sync.Yohumbus wrote:Alright... I've fixed it to the best I could. In Tales I still get a couple of screeches (not sure if that is the indication for being out of sync).
If you make a movie of the intro, then use the movie dump feature to just dump the audio and play it back, you shouldn't get any screeches, which demonstrates proper sound sync.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
_____________
Insane Coding
Well all I can suggest is that you try it out yourself and see if you cant get better sync because I only get screeches in a couple of parts and everything I can think of trying only makes the syncing worse. The only thing I can think of trying is to play with some frameskip because the code is designed to keep the buffers full, meaning that buffer underrun is probably what is causing them to get out of sync
When I tried to compile (on Gentoo Linux) the latest ZSNES SVN with your sdllink.c, the build fails with an error about O_DSP being undefined. It compiles fine and works great if I change the O_DSP to "/dev/dsp". Maybe assuming that O_DSP is defined isn't very portable?pagefault wrote:Updates:
No longer uses 100% CPU
Now syncs video to audio.
Checks to see if your card supports reporting the sound output delay.
Minor code cleanups.
http://zsnes.game-host.org/~pagefault/sdllink.c
Update #2
http://zsnes.game-host.org/~pagefault/synctest.c
Try this as well, this does a lot better job syncing the sound but also uses more CPU. May be an option later on.
Syncing
Does anyone who has both working (OSS wont work for me) want to see if there are signifigant differences in syncing problems between my version and OSS or are there no problems with the newest OSS version at. I played through Tales of Phantasia (fantastic game btw) and very rarely had any issues though the intro still consistently screeches a little.
I was wondering, why can't you use GStreamer (http://www.gstreamer.org/) or ESound (http://www.tux.org/~ricdude/EsounD.html)?
-
- New Member
- Posts: 3
- Joined: Mon Jun 19, 2006 10:36 am
Error compiling
Hi all, I'm running into a small glitch while trying to compile this new patch in. From a freshly downloaded/unzipped tarball of ZSNES 1.42 official, I'm deleting the stock sdllink.c from ./src/linux/ and downloading the new one to it.
With ./configure && make, I run into this issue:
This is on KnoppMyth with GCC 3.3.5. Any ideas?
Cheers
With ./configure && make, I run into this issue:
Code: Select all
gcc -pipe -I. -Wall -I/usr/local/include -I/usr/include -D__LINUX__ -I/usr/include/SDL -D_REENTRANT -D__OPENGL__ -O3 -ffast-math -fomit-frame-pointer -fexpensive-optimizations -s -march=pentiumpro -o linux/sdllink.o -c linux/sdllink.c
linux/sdllink.c:33:21: safelib.h: No such file or directory
linux/sdllink.c:34:25: ../asm_call.h: No such file or directory
linux/sdllink.c: In function `InitSound':
linux/sdllink.c:576: error: `O_DSP' undeclared (first use in this function)
linux/sdllink.c:576: error: (Each undeclared identifier is reported only once
linux/sdllink.c:576: error: for each function it appears in.)
linux/sdllink.c: In function `WriteSamples':
linux/sdllink.c:638: warning: implicit declaration of function `asm_call'
linux/sdllink.c: In function `LaunchURL':
linux/sdllink.c:1261: warning: implicit declaration of function `safe_fork'
make: *** [linux/sdllink.o] Error 1
Cheers
-
- New Member
- Posts: 3
- Joined: Mon Jun 19, 2006 10:36 am
Well, I did try with the Yohumbus version, but encountered all sorts of bad juju when trying to build that.
A quick snippet...
Should I be grabbing anything else, or does it look like my gcc version could be to blame?
A quick snippet...
Code: Select all
linux/sdllink.c:924: error: `AL_SOURCE_STATE' undeclared (first use in this function)
linux/sdllink.c:925: error: `AL_PLAYING' undeclared (first use in this function)
linux/sdllink.c:927: warning: implicit declaration of function `alSourcePlay'
linux/sdllink.c: In function `UpdateMenuSound':
linux/sdllink.c:937: warning: implicit declaration of function `alSourcePause'
linux/sdllink.c: In function `LaunchURL':
linux/sdllink.c:1502: warning: implicit declaration of function `safe_fork'
linux/sdllink.c: At top level:
linux/sdllink.c:121: warning: `MouseMoveX' defined but not used
linux/sdllink.c:121: warning: `MouseMoveY' defined but not used
{standard input}: Assembler messages:
{standard input}:1228: Error: symbol `SoundEnabled' is already defined
{standard input}:1234: Error: symbol `SoundEnabled' is already defined
{standard input}:1240: Error: symbol `SoundEnabled' is already defined
{standard input}:1246: Error: symbol `FirstOpenBuffer' is already defined
{standard input}:1253: Error: symbol `GameLastStreamed' is already defined
{standard input}:1343: Error: symbol `SoundUseFreq' is already defined
{standard input}:1349: Error: symbol `TBuffLen' is already defined
make: *** [linux/sdllink.o] Error 1
I've created a patch of Nach's version against the latest SVN (leaving out what I hope are just some whitespace changes). It sure seems to work, though on my slow system (450 MHz PII) with crappy sound (CS 4610/11), it still skips a little on the ToP intro.
http://naesten.dyndns.org:8080/oss.patch
http://naesten.dyndns.org:8080/oss.patch
This is a port of the previously-mentioned patch to the 0904 WIP. For me, the WIP has an extreme amount of crackling. This patch fixes the crackling.
http://www.fluffypenguin.org/gentoo/20060904-oss.patch
http://www.fluffypenguin.org/gentoo/20060904-oss.patch
It would probably help if people were to check the OSS manual before writing code. Where did that SNDCTL_DSP_SETFRAGMENT sample come from anyway? The manual calls for pointer to int containing two values, one in lower 16 bits and the other in the upper 16 bits, not a string.