win32 soundcard input?

[xoxos]

yap, the only place i've wilfully chosen to implement pointers outside of APIs and SDKs that require it, is passing arrays to an fft. the wording of the description made it sound like an address value :p (lol iirc when i made 'names' i intended to use pointers for the practice and then decided it was too silly to do it that way, plain outside of my conception)

will see where that gets me, thank you much, i'd probably never have known otherwise.

ty, that does correctly identify the returned buffer

[xoxos]

got to a point where i decided it might be more prudent to solicit input again..

again, thank you i've managed to integrate your script to my windows script with desirable gui and sound i/o performance. i've been trying to add processing between the inputs and outputs, perhaps my approach isn't the best -

in the thread call i added a function to send the buffer to my process..
WAVEHDR *pWH = &oHdr[index];
myprocess(pWH->lpData); // i added this
waveOutWrite(hWaveOut, pWH, sizeof (WAVEHDR));}

the argument is received as PBYTE in myprocess. i soon observed that the multithreaded buffer calls cross-modulated any global scope variables which cause profound distortion with any transformation (this will be useful in a few days).

i watched the length param of the delay graphic zip all over the place as the length modulation smoothing filter was in this process.. i have replaced all of the variables in the process with local scope but still awful

i've considered two solutions for this, perhaps there is a simpler option.. first, i expect that it would be prudent to give my audio process it's own thread and make it "mono", which i expect i'm a ways off doing.

the second approach would be to reinstitute the non-multithreaded petzold audio outs i was working with, see if i can stop 'yours' from accessing the outputs and try to pass the data from 'your' format to mine. i figure i have a better chance of being able to do that, but i also expect that it will create new problems eg. running non-multithread alongside multithread..

so.. thought i'd better ask..

[xoxos]

concrete:

Code: Select all

	for (int buffercount = 0; buffercount < BUFFER_SIZE; buffercount += 2) {
		int blow = pBuffer[buffercount];	int bhigh = pBuffer[buffercount + 1];
		short int mysample = (bhigh << 8) + blow;
		
		mysample /= 4;
		delay[p] = mysample;
		
		bhigh = mysample >> 8; // of course mysample clipped +- 32767
		blow = mysample;
		p++;	
		pBuffer[buffercount] = blow;
		pBuffer[buffercount+1] = bhigh;	
	}

delay[p] is drawn on the screen so i have visual confirmation that mysample centers at zero, looks like audio and all that nice stuff. if i remove mysample /=4 i hear pristine signal, with it in i get wrongness.

[mystran]

concrete:
delay[p] is drawn on the screen so i have visual confirmation that mysample centers at zero, looks like audio and all that nice stuff. if i remove mysample /=4 i hear pristine signal, with it in i get wrongness.

Just to sanity check: the buffer is declared "unsigned char" or something equivalent and not just "char" right? Otherwise you could get sign-extension messing things up... though I wonder.. is there some really good reason you don't just cast the buffer to (short*) and load from that directly?

[otristan]

Honestly, why bother when you could use PortAudio which has a very simple clean API
http://www.portaudio.com/

[xoxos]

Just to sanity check: the buffer is declared "unsigned char" or something equivalent

PBYTE

..I wonder.. is there some really good reason you don't just cast the buffer to (short*) and load from that directly?

<- colon d o g colon
ignorance

oristran - too much trauma. i'd seriously rather send developers parts of myself in the mail than adopt another sdk. bitwise's script is still my "giant" here but i can see all the words and there's a sensible volume of them.

i wrote my own aa graphics routines and because of it, they look better than eg. photoshop's lines (i crossfade like panning). i'm a simple, and untrusting person, ain't gonna happen

[antto]

i wrote my own aa graphics routines...

so did i, antialiased dot (of variable size, fractional coords and size) and antialiased line

i crossfade like panning

i did too, using sqrt() on the edges of the line/dot instead of just linear fade, and it looked very decent

however, some time later, i realized that what i was doing is wrong
linear fade is correct, it looks wrong because you do it directly in the rgb color space of the OS which is typically gamma compressed by 2.2 or something like that
what you should do is do these things in linear color space (then it's linear fade) and apply gamma compression to the RGBs to get the result ready for displaying
this final step is sort of:
gamma = 1/2.2; // or pick your favourite gamma factor
R = pow(r,gamma) * 255;
G = pow(g,gamma) * 255;
B = pow(b,gamma) * 255;
and, yes, this is sort of close to sqrt(), but it's not equivalent
...just sayin'

[xoxos]

thanks..

..and once again, i don't mind compromising my reputation to complain about that

not because i believe the public/have-nots are entitled to receive everything, but because there is so much information that is withheld.. eg. if you want to learn about game programming, don't bother going to gamedev.net (eg. gamedev tutorial on collisions = 2d rectangular bounding box... meanwhile there are dozens of blogs kids have written in their lunchtimes that treat the reader like a sapient creature). (watch gamma be the *one* thing they actually do have documentation for..) for all the time i spent trawling through graphics references, i may have seen information on gamma, but no discussion of application, ty.

and i really don't mind complaining about it since eg. photoshop are *still* (well last ed. i saw) using poorly rendered wu lines. check it out! but does anyone close enough punch them in the face? f**k what a useless society.

i'm going to leave this topic open as i'm not able to discern how to process the audio.

[xoxos]

here's a quick bit of fun
http://xoxos.net/temp/delay2.zip

very concise script. within the audio process, the sample values are scaled. if they are scaled at 1.0, the sound is good. as that value changes, distortion *increases*

what i am interested in, is not what i am doing wrong, but i would truly like to know -

if you can spot how to fix this by simply changing a cast or something, inform me at once, then i and everyone here will truly know for certain of my cretinous nature, and that i am simply not capable of applying knowledge. we'd all like for us all to know that, right?

[mystran]

i wrote my own aa graphics routines...

so did i, antialiased dot (of variable size, fractional coords and size) and antialiased line

Out of curiosity, how do you deal with poly-lines? I mean .. drawing those as polygons (convolve each line segment with a brush, draw the union) works .. but it's a bit slow .. and drawing every segment separately looks pretty ugly (especially when the polyline is from a subdivided curve) without brute-force MSAA (which is slow). For function plots (so one axis is a function of the other) it's not too hard to special case, but I'd love a good, fast, general solution for poly-lines.

however, some time later, i realized that what i was doing is wrong
linear fade is correct, it looks wrong because you do it directly in the rgb color space of the OS which is typically gamma compressed by 2.2 or something like that

Well, in practice sqrt() is equivalent to pow(x, 1/2.0) .. so using sqrt() as a cheap gamma hack is actually not that bad if you want to save a few cycles. While doing anti-alias resolves in linear display space (just don't do it in pre-tonemap HDR space, that looks horrible) might be more correct than doing it in gamma space, personally I usually prefer the gamma space results, actually. Also, the problem with linear space is that 8 bits/component won't really be enough then (which is why we use gamma space in the first place).

[bitwise]

here's a quick bit of fun
http://xoxos.net/temp/delay2.zip

very concise script. within the audio process, the sample values are scaled. if they are scaled at 1.0, the sound is good. as that value changes, distortion *increases*

what i am interested in, is not what i am doing wrong, but i would truly like to know -

if you can spot how to fix this by simply changing a cast or something, inform me at once, then i and everyone here will truly know for certain of my cretinous nature, and that i am simply not capable of applying knowledge. we'd all like for us all to know that, right?

Casting:

oo = (float)mysample * involfout;

doesn't scale the short into [-1, 1]


and casting:

int outi = (int)out;

doesn't scale the float into [-32768, 32767]


you need to divide and multiply.

[xoxos]

i had mentioned that reducing the scale results in greater distortion. you should try listening to it.

as i understand it, 32 bit floating point suffers from degradation at more extreme values, but i don't think that could account for the distortion. i don't see any reason why these simple operations would produce such profound degradation due to the scale, especially since the inputs and output are unity at maximum.

i've often worked in floats in the low tens of thousands before, though not so much in audio, and i've found them to have reasonable fidelity for most operations.

[bitwise]

i don't see any reason why these simple operations would produce such profound degradation due to the scale, especially since the inputs and output are unity at maximum.

mysample is 32767 at maximum

[xoxos]

that is exactly right. it is exactly at the scale of unity when handled as a short.

i could go to the trouble of coding a delay in a platform i have sufficient documentation for to illustrate that performing delay operations at that scale can be done without adverse effects.

you know, receive the audio in float, scale it by 2^15, do the delay, take the output, divide it and pass it out. and it wouldn't sound all crazy like that. but i can't see how that would help society.

you ought to check it out. that thing is dead wrong sounding.

[xoxos]

when this is all over and demonstrated that i'm screwing this up ben can change my tag to "dsp cretin", or just "cretin" of anything.