Working on reverse engineering the driver for this sound card, and ran into something to do with how Windows does sound.
In Linux, you cannot use floating point in the kernel, except for special cases. Windows must not have this limitation, because audio values in decibels are sent to the card, and they're in floating point.
Anyways, the standard for this sound card is Intel HD Audio, which only has decibel audio values in unsigned ints. So, it looks like Creative added a command that allows for decimals to be added.
I'm trying to figure out how the conversion between them is done, and if it's a common algorithm.
There's an 8 bit number which seems to represent the numbers after the decimal point. A few examples:
Decibel: 8.54 Decimal: 34
Decibel: 7.88 Decimal: 56
Decibel: 7.27 Decimal: 17.
It seems the multiplying the decimal number by 1.56 gets me around the number past the decimal, but there must be a more precise way of doing this. Maybe it's some formula Creative came up with. But I'm hoping it's something standard and someone here can identify it.
Working on reverse engineering the driver for this sound card, and ran into something to do with how Windows does sound
install gentoo
You'd be better off asking . Jow Forums is just /v/ with some freetards sprinkled in.
Sometimes I'll use lookup tables to mock routines I don't understand yet.
A given function might only be called a few times, or only with a few different parameter values
Knowing absolute jackshit about the subject I'm going to say it's just introducing randomized dithering since it's just a consumer piece of trash.
Thing is, I don't really NEED to understand this, because Linux doesn't use floating point, so all decibel values are just integers. It's more that it's bugging me that I can't accurately figure out what it's doing.
Let .00 to .99 be 0b00000000 to 0b01111111
I think your given values line up as if they were quantized to 7 bits
Not sure if I'm doing this right
I've thought about something like this, but I'm not sure it really helps. the value for decimal .99 is 3F, which is 63, almost 1/4 the total 8 bit size. Don't know if that has any relevance either.
Plot it out on a chart maybe?
Probably something like though.
Got it!
Assume integer division
(54 * 0x80) / 100 = 34
(88 * 0x80) / 100 = 56
(27 * 0x80) / 100 = 17
Do it backwards for the other way
Could you explain? I'm not getting your same results. I have to divide the result of the first part by two to get the equals number.
Okay, yeah, after dividing the result by two, I get the original number. Thanks user. Knew someone here would be smart enough to solve it.
Replace 0x80 with 0x40, my bad
You're essentially taking the values 0 to 99, and scaling them to the 64 (0x40) values between 0b000000 and 0b111111
I'm not so sure that linux having this limitation makes sense. Did you try casting the int to a float? Maybe you're looking at the floating point value casted to an int or unsigned int?
Glad I could help, thx
It's because in order to use the FPU, the kernel has to clear and save it's registers, do whatever it needs, and then restore the FPU registers. This also doesn't port well to other architectures, so in general you're not supposed to use floating point. RAID uses floating point, not sure if anything else does.
Double checked and it's true. Damn thats nuts. Why is audio processing done in kernel space?
It isn't really doing audio processing, it's just volume related stuff. On this particular card, it's only calculating it because the onboard DSP wants to know the volume of the audio it's being sent. I don't know what keeps it from detecting it itself, but there must be a reason.
>I'm reverse engineering
No you don't, you're guessing a function based on IO, not just disassembling the binary to see the exact instruction used by the driver
I saw a thread of yours earlier, how the fuck do you get started mucking around with drivers?
For me, I set a goal and then autistically work to it until I can get it. So, I really didn't just get into drivers. I got into it to fix this specifically.
I read parts of a book on Linux device drivers called ldd3, and then after I understood how Linux driver's worked I figured out how the Intel HD Audio standard worked. I started out programming an EEPROM for my car computer. I like this stuff because it's really logical. Just follow the datasheets, and it works.
kill yourself brainlet
you're worse than that guy "building" a monitor
post the assembly code
There's a guy doing that? Bretty cool, I thought about doing that at one point. There's a standard for monitor panels. It'd be neat to build one so you could overclock a monitor that doesn't let you from the factory.
I don't know where it is in assembly, I'm not disassembling, I'm just capturing communications.
Sounds like a cool project. Are you going to host the code you develop publicly?
Eventually I'm hoping to have it merged with the kernel. But I post the versions I've made so far to Google drive, and the program I've used to capture the sound card communication is on github. The volume is the last part, so once I've got this finished, I'm going to try to merge it with the kernel.
Godspeed on your reverse engineering.
Had to buy asau xonar soundcard because creative have no linux support.
Thanks user. I have everything working. If I had known I would have been using Linux in the future when I bought my PC, I probably would've gotten a Xonar.