Author Topic: SNDRAW  (Read 1475 times)

Artelius

  • Jr. Member
  • **
  • Posts: 64
    • Email
Re: SNDRAW
« Reply #30 on: February 13, 2011, 05:00:16 AM »
Got anything else?

_SNDSAMPS

which obviously ;) stands for SouND SAMples Per Second.


I don't like your choice of name. The term "frequency" could be confusing as it has an accepted meaning when it comes to audio. "Sample rate" or "sampling rate" is the term generally given to this property.

To be fair, "sampling frequency" is also used. But I think "FREQ" by itself is too ambiguous.


I like the idea of being able to support different sample rates.

One reason is because there are a few wav files I'm working with (under 1k) which become bigger if converted to ogg. I stuck with wav for the format, seeing that 22,050khz stereo file sizes are cut in half for things like sound effects which don't lose too much fidelity when sampled to 11,000khz mono instead. QB64 plays the 11khz sampled wavs at the correct speed as if they were 22,050 rather than speeding them up to double-speed. Will the _SNDRAW function treat with and mask sample rates the same way, or will we have to manage them carefully since we are reading raw data out of a bank chunks at a time?

We'd probably be best off with a short but sweet keyword that still says what it does, like maybe...
_SNDRATE 44khz
_SNDRATE 22khz
_SNDRATE 11khz
_SNDRATE 8khz


I don't think it should be _SNDRAW's job to convert from the input sample rate to the internal sample rate. If there were to be a means of requesting a sample rate, then it should control the internal sample rate and not another conversion layer in between. IMO.

Galleon

  • Administrator
  • Hero Member
  • *******
  • Posts: 4226
  • QB Forever
    • Email
Re: SNDRAW
« Reply #31 on: February 13, 2011, 05:01:26 AM »
It's a freq'n mutiny. _SNDRATE it is then. ::)

Galleon

  • Administrator
  • Hero Member
  • *******
  • Posts: 4226
  • QB Forever
    • Email
Re: SNDRAW
« Reply #32 on: February 13, 2011, 05:08:15 AM »
Quote
I don't think it should be _SNDRAW's job to convert from the input sample rate to the internal sample rate. If there were to be a means of requesting a sample rate, then it should control the internal sample rate and not another conversion layer in between. IMO.
Let's say I had raw sound data in a specific sample rate I wanted to play, but being new to programming I didn't have the knowledge/skills to perform the conversion to the internal _SNDRATE...
Or maybe I am writing an emulator for an old console in QB64 which uses a specific frequency my OS doesn't support internally...

Food for thought.

Is this conversion on the fly actually possible Artelius?

PS. In any case, this is something we can cater for later down the track.

PPS. Need sleep. I'll follow this up tomorrow.
« Last Edit: February 13, 2011, 05:15:22 AM by Galleon »

Artelius

  • Jr. Member
  • **
  • Posts: 64
    • Email
Re: SNDRAW
« Reply #33 on: February 13, 2011, 05:31:01 AM »
Is this conversion on the fly actually possible Artelius?

Sure the conversion is possible. Nearest neighbour will work, though linear interpolation sounds better and cubic interpolation sounds even better. I'm sure there are other ways to do this that sound even better. Given all these choices I think it's better to leave the responsibility to programs rather than doing conversion internally.

Nearest neighbour and linear interp are not much code. Cubic interp is a bit more code.


Let's say I had raw sound data in a specific sample rate I wanted to play, but being new to programming I didn't have the knowledge/skills to perform the conversion to the internal _SNDRATE...

How does a beginner "have" raw sound data? If he has a WAV file, he can use _SNDLOAD.

A beginner might create raw sound data ("What does a sine wave sound like?") in which case there is no problem but I find it unlikely that a beginner will want to do stuff with prerecorded sound that can't be done with _SNDLOAD.


P.S. Need sleep too.
Was it just me or have you noticed a lot of flies in the past couple of days?

OlDosLover

  • Hero Member
  • *****
  • Posts: 2722
  • OlDosLover
    • Email
Re: SNDRAW
« Reply #34 on: February 13, 2011, 05:50:52 AM »
Hi all,
    Agreed lots flies.
OlDoslover.

SkyCharger001

  • Hero Member
  • *****
  • Posts: 1391
Re: SNDRAW
« Reply #35 on: February 13, 2011, 10:37:24 AM »
In most cases no actual re-sampling is required.
this is due to the principle of subharmonics.

Mega

  • Sr. Member
  • ****
  • Posts: 295
  • Who GNU?
Re: SNDRAW
« Reply #36 on: February 13, 2011, 05:41:38 PM »
It's freebasic's fault. When it doesn't stink, it's just...fly-by-night. ;) So do we have an official consensus on the new SNDRAW structure and how it will work for the wiki, or will that be post-release of the next version? (Was looking at the demo from Artelius and wondering how much of that will change with standard code implementation on qb64). Also, will this addition be uniform on all releases (mac, linux, win) or is the next update only for win32 with this?
Just an old-school programmer of covox speech things and such...

Artelius

  • Jr. Member
  • **
  • Posts: 64
    • Email
Re: SNDRAW
« Reply #37 on: February 14, 2011, 06:37:00 AM »
Also, will this addition be uniform on all releases (mac, linux, win) or is the next update only for win32 with this?

I've been developing solely on Linux, so it definitely works there. I don't see any problems with it working on Windows and presumably Galleon already has tested it on Windows. Feel free to test for yourselves, I'd like some more feedback :)

So do we have an official consensus on the new SNDRAW structure and how it will work for the wiki

I think we do.

_SNDRATE (returns the sampling rate)
_SNDRAW mono# (queues a sound value between -1 and 1 on both channels)
_SNDRAW left#, right# (queues a different value between -1 and 1 on each channel)
_SNDRAWLEN (returns the length, in seconds, of sound currently queued)

Important notes:
  • Using _SNDRAW will pause any currently playing music. (You'll have to generate your own :).)
  • _SNDRAW is designed for continuous play. It will not produce any sound until a significant number of samples have been queued. Do not expect to hear anything if you only queue one or two samples.
  • Ensure that _SNDRAWLEN is comfortably above 0 (until you've actually finished playing sound). If you are getting occasional random clicks, this generally means that _SNDRAWLEN has dropped to 0 (unless of course there happen to be clicks in the sound you're playing).
  • _SNDRAW is not intended to queue up many minutes worth of sound. It will probably work but will chew up a lot of memory (and if it gets swapped to disk, your sound could be interrupted abruptly).
  • _SNDRATE tells you how many samples are played per second. However, the timing is achieved by the sound card, not your program. Do not attempt to use _TIMER or _DELAY or _LIMIT to control the timing of _SNDRAW. You may use them as usual for delays or to limit your program's CPU usage, but the decision of how much sound to queue should only be based on _SNDRAWLEN.


The explanation and demo program I gave at the end of Page 1 is still accurate, though replace _SNDRAWQUEUE with _SNDRAW and 22050 with _SNDRATE.

I'm not sure if the word "samples" is easy enough to understand. Maybe "values" would be better. Any other suggestions? I think it would be a good idea to explain briefly how digitised sound works at the start of the wiki page.


Artelius