Tír Na HiFi

sbgk wrote:Hi Lekt,

am interested in what you've been doing with conversion of getbuffer and releasebuffer to c, would you be prepared to share some info ? Is there anything from MQn you'd be interested in in exchange - hirez formats, assembly code etc ?

how many tricks i've used in C native code for lekt.exe, now C code is going to near limited SQ. need make player by assembly or embed assembly into C. tried embed some testing simple assembly code but can not compile to .exe, hehe... my knowledge about MASM ~zero now. need time to learning it.
i think my C code now easy transfer to assembly, all things used by integer numbers, no object, no C interface. already to assembly, even all needed wasapi manipulations.

"...what you've been doing with conversion of getbuffer and releasebuffer to c"
i can share to you some ideas, maybe usefull for mqn code:
from CoCreateInstance(...) to last wasapi ReleaseBuffer(...) function: need working with (and only) function pointers, i use unsigned __int64 or unsigned long long. no C++/C object and its interface coz they slowly run and make sound not clean. one month i've manually searching their memory pointer/address, like as hacker, as JC said about me. haha...
OK, we with you will do some interested exchange. i will send message to you. thanks, sbgk.

ok, that's good news. I thought you'd broken the getbuffer and releasebuffer function down to the code below. MQn handles the pointers by storing them in registers, so there are no variables in memory.

existing many tricks with code. im thinking how intergrate to release version idea as follow:
in each working session of windows almost wasapi function pointers are constants, fixed 64bit integer number. try test them by printf(), sbgk.
after windows restaring these numbers have changed, but low part of pointer still constant, think for 4gb, 8gb, 16gb RAM they are different but constants for each laptop/PC. not sure, in my case always constant. so then i builded for me version with function calls by only constant pointers. very interesting, of course SQ much better. try make own mqn for you.
how intergrate this idea to release version for people. maybe store them into binary file or windows registry and get them once time but result will be variable. can get benefit but not much. hmm...

here is the render assembly code, all function pointers, immediates, etc are held in registers, suppose [imp_WaitForSingleObjectEx] should also be in a register.

can't see any point in hardcoding the pointer values, they still need to go into a register at some stage. The thing to avoid is having the pointer in memory. For the buffer register I just add or subtract 1024 to it depending on which buffer is current.

ie
sub r12, rbx ; 400010D9 _ 4C: 2B. E3
neg rbx ; 400010E3 _ 48: F7. DB

assembly code

mov r13, -128 ; 40001014 _ 49: C7. C5, FFFFFF80
mov r15, -3072 ; 4000101B _ 49: C7. C7, FFFFF400
lea r8, [rsp+38H] ; 40001022 _ 4C: 8D. 44 24, 38
mov rax, qword ptr [rcx] ; 40001027 _ 48: 8B. 01
mov r9, qword ptr [rcx+8H] ; 4000102A _ 4C: 8B. 49, 08
movq xmm1, r9 ; 4000102E _ 49: 0F 6E. C9
mov r9, qword ptr [rcx+10H] ; 40001032 _ 4C: 8B. 49, 10
mov rdi, r9 ; 40001036 _ 49: 8B. F9
mov rbp, qword ptr [rcx+18H] ; 40001039 _ 48: 8B. 69, 18
mov esi, 4294966784 ; 4000103D _ BE, FFFFFE00
mov qword ptr [rsp+38H], rax ; 40001042 _ 48: 89. 44 24, 38
mov rbx, rcx ; 40001047 _ 48: 8B. D9
mov r14, qword ptr [rbx+20H] ; 4000104A _ 4C: 8B. 73, 20
mov r12, qword ptr [rsp+38H] ; 4000104E _ 4C: 8B. 64 24, 38
mov rcx, qword ptr [rbx+28H] ; 40001053 _ 48: 8B. 4B, 28
or edx, 0FFFFFFFFH ; 40001057 _ 83. CA, FF
movq xmm0, rcx ; 4000105A _ 48: 0F 6E. C1
movq xmm2, r8 ; 4000105E _ 49: 0F 6E. D0
mov rbx, 3072 ; 40001062 _ 48: C7. C3, 00000C00
; Filling space: 0FH
; Filler type: Multi-byte NOP
; db 0FH, 1FH, 40H, 00H, 0FH, 1FH, 40H, 00H
; db 0FH, 1FH, 80H, 00H, 00H, 00H, 00H

ALIGN 8
?_002: call qword ptr [imp_WaitForSingleObjectEx] ; 40001078 _ FF. 15, 00000FD2(rel)
; Filling space: 2H
; Filler type: NOP with prefixes
; db 66H, 90H

ALIGN 8
?_003: vmovdqa ymm0, ymmword ptr [r15+r14] ; 40001080 _ C4 81 7D: 6F. 04 37
vmovdqa ymm1, ymmword ptr [r15+r14+20H] ; 40001086 _ C4 81 7D: 6F. 4C 37, 20
vmovdqa ymm2, ymmword ptr [r15+r14+40H] ; 4000108D _ C4 81 7D: 6F. 54 37, 40
vmovdqa ymm3, ymmword ptr [r15+r14+60H] ; 40001094 _ C4 81 7D: 6F. 5C 37, 60
vmovdqa ymmword ptr [r15+r12], ymm0 ; 4000109B _ C4 81 7D: 7F. 04 27
vmovdqa ymmword ptr [r15+r12+20H], ymm1 ; 400010A1 _ C4 81 7D: 7F. 4C 27, 20
vmovdqa ymmword ptr [r15+r12+40H], ymm2 ; 400010A8 _ C4 81 7D: 7F. 54 27, 40
vmovdqa ymmword ptr [r15+r12+60H], ymm3 ; 400010AF _ C4 81 7D: 7F. 5C 27, 60
sub r15, r13 ; 400010B6 _ 4D: 2B. FD
jnz ?_003 ; 400010B9 _ 75, C5
xor r8d, r8d ; 400010BB _ 45: 33. C0
movq rcx, mm1 ; 400010BE _ 48: 0F 7E. C9
sub edx, esi ; 400010C2 _ 2B. D6
call rbp ; 400010C4 _ FF. D5
movq r8, mm2 ; 400010C6 _ 49: 0F 7E. D0
movq rcx, mm1 ; 400010CA _ 48: 0F 7E. C9
sub edx, esi ; 400010CE _ 2B. D6
call rdi ; 400010D0 _ FF. D7
sub r15, 3072 ; 400010D2 _ 49: 81. EF, 00000C00
sub r12, rbx ; 400010D9 _ 4C: 2B. E3
movq rcx, mm0 ; 400010DC _ 48: 0F 7E. C1
sub edx, 1 ; 400010E0 _ 83. EA, 01
neg rbx ; 400010E3 _ 48: F7. DB
sub r14, r15 ; 400010E6 _ 4D: 2B. F7
jmp ?_002 ; 400010E9 _ EB, 8D

3072 and 1 are immediates as no more registers to use

not easy understand algorithm that's you posted, but i think your assembly render loop already OK, MQn always give perfect vibration comparing with other players writen by C code.
i feel soundstage/weight... and some factors maybe still have little issues. maybe read file method, get wasapi COM function pointers method still affect to sound. what code do you perform these tasks? assembly or C++, C ?
will transfer my code working with wasapi to more understandly and share to you later, maybe interested. now variables named only one letter a,b,c x,y,z... in code. even difficult read for me.
my laptop onboard sound card works with render loop without getbuffer and releasebuffer in loop, but JC can't use this version. will try again for his.
big result, much reduced latency. prefer this trick, but only i can use. why doesn't work in PCIe soundcard, not sure.

lekt wrote:not easy understand algorithm that's you posted, but i think your assembly render loop already OK, MQn always give perfect vibration comparing with other players writen by C code.
i feel soundstage/weight... and some factors maybe still have little issues. maybe read file method, get wasapi COM function pointers method still affect to sound. what code do you perform these tasks? assembly or C++, C ?
will transfer my code working with wasapi to more understandly and share to you later, maybe interested. now variables named only one letter a,b,c x,y,z... in code. even difficult read for me.
my laptop onboard sound card works with render loop without getbuffer and releasebuffer in loop, but JC can't use this version. will try again for his.
big result, much reduced latency. prefer this trick, but only i can use. why doesn't work in PCIe soundcard, not sure.

removing getbuffer and release would be good, do you replace them with something else ? I found some code that someone had written to replace these on osx so it could run windows, can send a link if I can find it.

do you massage the data ? Is that what the fibonacci comment is about ?

the player has no file read code, the control starts the player, the player allocates memory and the control gets the address of the memory then loads it with data and then hands off to the player. communication by reading bytes in the allocated memory ie when =1 then the data is loaded and the playback can start. it's c++, but with minimised winmaincrtstartup and no dll linking. when I had the file code in the player I did convert it to c functions, but never compiled the whole thing as c, would be interested to know how to do that.

2.96.2 nos is actually goood
near zero earaches...
most relax and casual of all lekt, i think
can play jazz, relaxing happy music
cannot play rock... weight not enough

add this my new favorite

sbgk, wondering if mqn.exe2.2 uses assm coding already? file read or memory play?

lekt, nos is goood... use of weight is improving/more correct.
music notes are improving.

most lekt versions play music notes too suddenly.

there are many ways to play music notes...
by human force.
by natural gravity.
by force+gravity.
by restrain.

nos is getting more correct in musical notes.
it can still be much better!!

goooheaven... forgot to tell u...

pls upgrade your clockrate to 132*2/44100=59864

132*2=264 works better with 256

(the old clockrate 132*3 only works best for 128)