Previous Thread
Next Thread
Print Thread
Page 2 of 4 1 2 3 4
Joined: Jan 2006
Posts: 138
M
Senior Member
Offline
Senior Member
M
Joined: Jan 2006
Posts: 138
Originally Posted By disturbedite
ha. i'm assuming that was meant for rb. and either way, i'm no programmer, but that was an amusing rant...

No, it was directed at the GCC compiler.

Joined: Mar 2001
Posts: 16,923
Likes: 57
R
Very Senior Member
OP Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,923
Likes: 57
And MAME/MESS's NES code isn't derived at all from NEStopia (or vice-versa). It's not bad after Brad Oliver's last rewrite, and it runs most of the trickier games fine, but it won't e.g. pass blargg's super-secret cycle-accuracy tests of doom.

Last edited by R. Belmont; 03/22/07 04:49 AM.
Joined: Feb 2007
Posts: 267
Senior Member
Offline
Senior Member
Joined: Feb 2007
Posts: 267
ha. ok. i know mame's nes code wasn't derived from nestopia, i know the mame nes support pre-existed nestopia, i was just asking whether any of nestopia's code was ever contributed to mame. if it sounded like something else i'm sorry, maybe i wasn't clear enough...

Joined: Jan 2005
Posts: 154
Senior Member
Offline
Senior Member
Joined: Jan 2005
Posts: 154
Originally Posted By "Marty"
This one is a bit more understandable but I still wish there were a way to turn it off in GCC. [...] Ok, the compiler starts whining so to shut it up, you change it to:
b = (char) a;
Later, you revisit your code and make a few changes:
double a = 300;
short b;
Now, enjoy your totally unnecesary bug.

Yes! This is my big gripe against people who claim all warnings are good. They ignore cases like this where the fix for the warning makes the code more brittle. The non-brittle fix is just ugly:
Code:
typedef char b_type;
double a = ...;
b_type b;
...
b = (b_type) a;


Joined: Feb 2004
Posts: 55
E
Member
Offline
Member
E
Joined: Feb 2004
Posts: 55
I tried the new preview release 4. No more crashes or hangs, thank you, but sound plays with distortion when ALSA is selected, OSS plays fine. I revert some differences from preview 3 and got ALSA sound fixed when inserted in oss.cpp the functions to set buffer size and number of periods before the call of function snd_pcm_hw_params. Only setting buffer size had no effect, only setting number of periods slow down emulation, but the two calls together solve the problem with my old Sound Blaster 16 PCI. Has the use of those functions had confirmed problems?

I notice hwparams being freed only after the call to snd_pcm_hw_params, but before there are more return conditions that could cause a minor memory leak, I think, but not a big problem to worry about.

Joined: Mar 2001
Posts: 16,923
Likes: 57
R
Very Senior Member
OP Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,923
Likes: 57
Well, the currently recommended practice with ALSA is to NOT set either the number of periods or the buffer size, because a lot of drivers have specific settings for those in mind and will not work if you attempt to override them (for instance, whatever disturbed is running). Emu10k1 works both ways - if the SB16 PCI doesn't, that's IMO a bug in the kernel driver. Please name open-source ALSA apps that do work on that card.

Last edited by R. Belmont; 03/25/07 05:23 AM.
Joined: Feb 2004
Posts: 55
E
Member
Offline
Member
E
Joined: Feb 2004
Posts: 55
I recently reinstalled Linux, so I just tested these apps to make sure they are working with new kernel/driver:

xmms (output_plugin=/usr/lib/xmms/Output/libALSA.so)
mplayer -ao alsa
mednafen -sounddriver alsa

All three played without problems. About buffers and periods, mednafen show the line below when running:

Buffer size: 1536 sample frames(32.000000 ms)

XMMS has settings that could be changed in its config file ~/.xmms/config:

[ALSA]
buffer_time=500
period_time=50
mmap=TRUE
pcm_device=default
mixer_card=0
mixer_device=PCM
soft_volume=FALSE
volume_left=100
volume_right=100

I can compile xmame with alsa and install more apps if you need more tests.

Joined: Feb 2007
Posts: 267
Senior Member
Offline
Senior Member
Joined: Feb 2007
Posts: 267
@enik
Originally Posted By R. Belmont
Well, the currently recommended practice with ALSA is to NOT set either the number of periods or the buffer size, because a lot of drivers have specific settings for those in mind and will not work if you attempt to override them (for instance, whatever disturbed is running).


rb is right. it didn't wfm before. fyi, i have a much newer sound card than yours. (i believe, 2004). even tho its a crappy one compared to today's standard. and in actuality, its not a sound card per se, its an integrated chip. (i'm on a p4 board). linux tells me it is an: Intel 82801DB-ICH4. or at least thats what driver is being used. in winxp i had a 3rd party driver, which is what it shipped with, so i updated it subsequently with that same driver and the card/chip was referred to as "SoundMAX Integrated Digital Audio". (i forget the exact model).
alsa & oss wfm only since preview 4.

Joined: Mar 2001
Posts: 16,923
Likes: 57
R
Very Senior Member
OP Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,923
Likes: 57
That's the Intel HDA driver, right?

Joined: Feb 2004
Posts: 55
E
Member
Offline
Member
E
Joined: Feb 2004
Posts: 55
Sorry for the long post. More information obtained after insert the first code below at beginning of m1sdr_Init() and the second at before "snd_pcm_hw_params_free(hwparams);"

Code:
     unsigned int periodsperbuffer, periodtime, buffertime;
     snd_pcm_uframes_t buffsize, periodsize;


Code:
     snd_pcm_hw_params_get_periods(hwparams, &periodsperbuffer, 0);
     printf("Approximate periods per buffer is %d.\n", periodsperbuffer);

     snd_pcm_hw_params_get_period_size(hwparams, &periodsize, 0);
     printf("Approximate period size is %d frames.\n", periodsize);

     snd_pcm_hw_params_get_period_time(hwparams, &periodtime, 0);
     printf("Approximate period duration is %d useconds.\n", periodtime);

     snd_pcm_hw_params_get_buffer_size(hwparams, &buffsize);
     printf("Buffer size is %d frames.\n", buffsize);

     snd_pcm_hw_params_get_buffer_time(hwparams, &buffertime, 0);
     printf("Buffer time is %d useconds.\n", buffertime);



1) Default of release 4 (sound plays with distortion):

Approximate periods per buffer is 1024.
Approximate period size is 16 frames.
Approximate period duration is 362 useconds.
Buffer size is 16384 frames.
Buffer time is 1 useconds.

Buffer size and periods per buffer ratio is 16:1.

2) After insert only buffer size setting of release 3 (still distortions):

Approximate periods per buffer is 512.
Approximate period size is 16 frames.
Approximate period duration is 362 useconds.
Buffer size is 8192 frames.
Buffer time is 1 useconds.

Periods per buffer automatically decreases to 512 (ratio 16:1).

3) After remove buffer size setting and insert only periods per buffer of release 3 (slow emulation):

Approximate periods per buffer is 4.
Approximate period size is 16 frames.
Approximate period duration is 362 useconds.
Buffer size is 64 frames.
Buffer time is 1451 useconds.

Buffer size automatically decreases to 64 (ratio 16:1), buffer time increases.

4) Default of release 3 (sound plays fine):

Approximate periods per buffer is 4.
Approximate period size is 2048 frames.
Approximate period duration is 46438 useconds.
Buffer size is 8192 frames.
Buffer time is 1 useconds.

Buffer size and periods per buffer ratio is 2048:1, period duration increases.

5) If I set buffer size to 8192 frames and start to decrement periods per buffer from 512 to 256, 128, 64, 32, 16, distortion is still present and emulation speed increases, but when it reaches 8 (ratio 1024:1), speed is normal and distortion disappears.

- Periods per buffer = 16, emulation too fast:
Approximate periods per buffer is 16.
Approximate period size is 512 frames.
Approximate period duration is 11609 useconds.
Buffer size is 8192 frames.
Buffer time is 1 useconds.

- Periods per buffer = 8, everything is fine like preview 3, which uses periods = 4:
Approximate periods per buffer is 8.
Approximate period size is 1024 frames.
Approximate period duration is 23219 useconds.
Buffer size is 8192 frames.
Buffer time is 1 useconds.

6) If buffer size is set to 16384 frames (default), but I change periods per buffer from 1024 to 16 (ratio 1024:1), sound plays without distortion and with normal emulation speed.

Approximate periods per buffer is 16.
Approximate period size is 1024 frames.
Approximate period duration is 23219 useconds.
Buffer size is 16384 frames.
Buffer time is 1 useconds.

7) I changed attention to period size. Settings of buffer size and periods per buffer were removed and only a call to set period size was inserted, using 1024 frames and decreasing later. It's very difficult to distinguish sound quality, but distortions seems to appear when period size is minor than 735. This size gives a interesting period duration:

Approximate periods per buffer is 22.
Approximate period size is 735 frames.
Approximate period duration is 16666 useconds.
Buffer size is 16384 frames.
Buffer time is 1 useconds.

The call to set period size was changed to snd_pcm_hw_params_set_period_time_near() and I got similar results, but time based (fine when 16666us or more).
Maybe a call to set period size to 735 or more (around 1024), or to set period time to 16666 or more (around 20000us) would be a solution to everyone. Comments? What are the numbers used by your sound setup, Arbee?


Page 2 of 4 1 2 3 4

Moderated by  Marty, R. Belmont 

Link Copied to Clipboard
Who's Online Now
1 members (Pernod), 19 guests, and 2 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics9,102
Posts119,263
Members5,019
Most Online890
Jan 17th, 2020
Our Sponsor
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!

Superior Solitaire
Forum hosted by www.retrogamesformac.com