-
Fototrend
Fototrend
Új hozzászólás Aktív témák
-
emitter
őstag
neked meg mindenképp azt ajánlom, hogy áruld el a feladatod mibenlétét, mert így nagyon nehéz segíteni
NEM röhögünk ki senkit, ha bizonytalan vagy, privizhetsz is 
amúgy realtime akármilyen programot szövegszerkesztésre használva szvsz lehetetlen ilyet csinálni.. vagy ahhoz már a billentyűzet driverjét kéne átírni
-
emitter
őstag
ez választható feladat vagy mi? ha ránézésre nem tudod eldönteni, hogy bonyolult-e vagy nem, akkor meggondolnám a helyedben, mielőtt belevágom a fejszémet
azért itt egy jó kis leírás [link] a hálózatos programozás alapjairól, neked különösen ajánlom átolvasni a ''6.2. select() - Szinkron I/O Multiplexelés'' részt, azon belül találsz egy nagyon egyszerű példát egy chat-programra, amit továbbfejleszthetsz
sok sikert!
mod: a link
[Szerkesztve] -
emitter
őstag
köszi, erre a select-es bibre sosem jöttem volna rá magamtól
most már nem eszik prockót
a ciklus azért fut bufsize-ig, mert akkora a puffer (wav_buf) mérete (ami ugye shortokat tartalmaz)
ha átírom a cilusokat, és csak readbytes-ig futnak, akkor már tényleg megszólal a zene, de nagyon zavarosan, zajosan.. ez nem tudom mitől lehet
(frissítettem a forrásokat a neten)
másrészt azért is gondolom, h a cilusoknak bufsize-ig kell futniuk, mert itt van pl. ez a progi [link], ez volt az alapja a wav-lejátszásnak, és itt is bepakolom a wavot egy listába (egy bufsize-ih futó ciklussal), amiből szépen vissza is tudom rakni a pufferba.. na és ha ebben a progiban átírom a ciklust, és csak readbytes-ig fut, akkor néha ugyan jól lejátsza a wavot, de sokszor hibát ad vissza az snd_pcm_writei()
szóval ezért maradnék a bufsize-ig futó cilkusnál
[szerk: ] ja és a buflevel nem a listában lévő bájtok számát mutatja, hanem a benne lévő wav_buf-ok számát, azaz pl ha buflevel 16, akkor van benne 16*bufsize*sizeof(short) bájt
[Szerkesztve] -
Jester01
veterán
Ez a bufferelés egy nagy káosz nekem. Nem igazán értem ki kivel van.
Elõször ott van ugye a buflevel. Gondolom ez mondja meg mennyi byte van már a bufferben. Utána van egy ciklus ami wi->bufsize-ig fut Az snd_pcm_writei pedig már readbytes mennyiséget küld a hangkártyának. -
Jester01
veterán
Azért ugrik meg a procihasználat, mert megállított állapotban nyilván nem kellene a select writefds közé a socket. Hiszen hiába is tudnál írni a hálózatra ha egyszer nem akarsz. Szóval most a select rögtön visszatér, hogy hajrá küldjél adatot, te viszont nem csinálsz semmit. Vagyis ott pörög a szerencsétlen.
A többit még nézem, majd jövök
-
emitter
őstag
nem igazán értem, ami gondolsz..
beraktam, vagy nem így kéne?
----------
FD_ZERO(&readfds);
FD_ZERO(&writefds);
FD_SET(STDIN, &readfds);
FD_SET(data_fd, &writefds);
while(!feof(handle)){
tv.tv_sec = 0;
tv.tv_usec = 0;
select(data_fd+1, &readfds, &writefds, NULL, &tv);
if( FD_ISSET(STDIN, &readfds) ){
cout << ''\nBillentyu lenyomva!\n'';
exit(1);
...
--------
mit jelent az hogy lehet írni a hálózatra? ezt nem értettem
szerk: ja elfelejtettem hogy így sem megy - hiába nyomom akár folyton az entert, nem lép ki a progiból
[Szerkesztve] -
emitter
őstag
újra a select()-tel vannak problémáim... mégpedig az, hogy túl nagy a minimum-időintervalluma (1 mikrosec.), amíg várakozik
nekem nagyon kicsi ideig kéne csak h megnézze az STDIN-t, különben nem tudja a progi elég gyorsan adagolni a hálózatra a wavot...
ja és mindez azért kéne, hogy tudjak wavjátszás közben pause-zni, stb.
most így selectelek:
---------
fd_set readfds;
struct timeval tv;
...
FD_ZERO(&readfds);
FD_SET(STDIN, &readfds);
while(!feof(handle)){
tv.tv_sec = 0;
tv.tv_usec = 1; // még 1 usec is nagyon sok idő neki
select(STDIN+1, &readfds, NULL, NULL, &tv);
if( FD_ISSET(STDIN, &readfds) ){
cout << ''\nBillentyu lenyomva!\n'';
return 0;
}
...//itt olvasok a wavból, és send()-elem el
------ nagyon jó lenne, ha nem kéne lemondanom a lejátszás vezérléséről... szóval csak van erre vmi megoldás -
emitter
őstag
az az érzésem, hogy a send lényegesen gyorsabban küldi az adatokat, mint ahogy én fogadni meg közben lejátszani tudom... ez előfordulhat? mert csak 2-3x fut le a main loop a szervernél, azaz csak 2-3x írja ki, h ''readbytes: xx'', bár ezt is rosszul, mert csak az első kiírásnál helyes az adat..
-
emitter
őstag
asszem megvan: a new hívás után ráállítottam még a data-t egy másik változó címére...
szóval pl ehelyett
data = &wi.channels;
ezt írom:
*data = wi.channels;
de így sem jó a dolog, éppúgy csak az első átvitt adat helyes, a több random
akkor mi történik, ha nem new-val rakok alá memót, hanem simán alátolom egy létező válozó címét - és ezután kiadok egy delete data; utasítást? ekkor csak leáll róla, vagy törli a wi.channels-t?
pl.
data = &wi.channels;
delete data; -
emitter
őstag
értem, köszi
ez egyre jobb.. teljesen kész vagyok: fordítom mindkét progit (server, kliens), ezután első futtatásra teljesen jól átjönnek az adtaok, minden OK, úgy ahogy szeretném
ezután második futtatásra már tök random cuccok érkeznek meg
ez mitől lehet?!
csak az újrafordítás segít ezen..
na, felrakom a forrásokat, íme
server: [link]
kliens: [link] -
emitter
őstag
igazad volt, még így látatlanban is megtaláltad a hibát
most viszont már a send() és recv() hívásokkal vagyok bajban, mert kiküldök send-del egymás után 3 adatot (mindegyik más hosszúságú char*), majd ezeket szeretném recv-elni, ami nem sikerül.. az első adat rendben megérkezik, a többi viszont sehogy sem akar eredeti formájában megérkezni..
ha jól tudom, ezek a hívások blokkolnak, szóval olyan nem lehet, hogy elmulasztok egy adatcsomagot a szinkronizáció hiánya miatt, ugye?
a kódot azért nem raknám be, mert tele van mindenféle debug-kiíratásokkal, még nekem is nehéz átlátni de ha gondolod, belinkelhetem..
szóval elvileg előfordulhat olyan, hogy sendelek 1 csomagot, megérkezik (ezután a fogadó oldalon csinálok egy csomó mindent - emiatt elképzelhető, hogy a következő csomag még eközben érkezik meg, így a fogadó fél lecsúszik a fogadásáról? van ilyen - vagy az oprendszer eltárolja vmi bufferban a beérkezett csomagokat?) -
Jester01
veterán
-
emitter
őstag
sprintf() köszi! ezzel jó
viszont újabb értelmetlen dolog előtt állok, van ez a kódrészlet:
cout << ''elotte\n'' << endl;
fseek(handle, wi.fp, SEEK_SET);
cout << ''utana\n'' << endl;
//komment kezdete
sprintf( buf_int, ''%d'', wi.sample_rate);
i = strlen(buf_int);
if(send(data_fd, buf_int, i, 0) == -1){
perror(''send'');
exit(1);
}
sprintf( buf_int, ''%d'', wi.bits_per_sample);
i = strlen(buf_int);
if(send(data_fd, buf_int, i, 0) == -1){
perror(''send'');
exit(1);
}
//komment vege
cout << ''elotte\n'' << endl;
fseek(handle, wi.fp, SEEK_SET);
cout << ''utana\n'' << endl;
----------
namost ez a következőt csinálja:
elotte
utana
elotte
Szegmens hiba
ha viszont a ''komment kezdete'' és a ''komment vege'' közti részt kikommentelem, akkor nem ad hibát, hanem
elotte
utana
elotte
utana telejesen értetlen vagyok.. -
emitter
őstag
linuxon hogyan tudok integerből, ill. short-ból char*-ot csinálni?
stdlib.h-beli itoa()-ra ''was not declared in this scope'' dob..
másik kérdés, hogy fordítva hogyan tudok shortot csinálni a char*-ból? integer megy egy sima (int) castolással, de short-ra nem engedi, merthogy elveszti a pontosságát a szám - ez logikus, de akkor hogyan csináljam -
emitter
őstag
most még annyit kéne alakítani rajta, hogy legyen egy olyan pufferem, aminek a szintjét nem engedem pl. 30% alá menni (ez jó lenne a hálózati sebesség-ingadozások ellen)
szóval ebbe a nagy-nagy pufferba kéne pakolni sok-sok ilyen listát.. namost ezt hogyan
[Szerkesztve] -
emitter
őstag
hehe
télleg!
akkor azt hogyan oldjam meg, hogy a listába 4096bájt méretű elemeket pakoljak? merthogy nekem nem csak egy elem első bájtját kell átküldenem majd a hálózaton hanem mindet
vagy nem is kell 4096, de mondjuk 256 azért kellene..
Tyrael: nem tudom, nem lenne-e túl lassú tőle a dolog de lehet h kipróbálom
[Szerkesztve] -
emitter
őstag
az hogyan lehet, hogy én egy list<short>-ba bele tudok gyömöszölni pl 4096 bájtot?
így csinálom:
...
list<short> myList;
short *buf;
...
bufsize=4096;
i = fread(buf, 1, bufsize, handle);
myList.push_back(*buf);
*buf=myList.front();
...
snd_pcm_writei (playback_handle, buf, tmp);
...
és jól lejátsza a cuccost szóval ezt hogyan? -
emitter
őstag
hát én ebből azt szűrtem le, hogy van a ''data'' string a 40-es offsettől, majd 4 bájt SubChunkSize (nemtom miez), majd így a 48.ik offset-től kezdődik az igazi stream
következőképpen:
mintánként 2 bájt bal-, majd 2 bájt jobb csatorna (egy hexa-kód (szám, betű) 4bit - tehát ha egy minta 3c f2 24 f2, akkor ebből 2 bájt (3c f2) a bal csati, és 2 bájt ( 24 f2) a jobb csati)
nem műxik így? azt nem tudom, h ez a szabványos wav, de elvileg annak kell lenni, mert nem írták, h nem így lenne
[Szerkesztve] -
ALI_G
veterán
igen, ezt én is ismerem, bár ennél van jobb is, ami viszont nincs ilyen részletes. [link] én ez alapján próbáltam szétbontani fejben. Van 1 példa is. Az a nagy kérdés most, hogy mitől függ hány byte-onként váltakoznak a csatornák adatai. Le van írva, de akárhányszor kibogozom, más jön ki...
tuti én vok a béna. -
emitter
őstag
köszi az észrevételeket, kijavítottam
viszont tényleg nemtom, h mitől nem bírja nromálisan átadni a FILE* mutatót, szal inkább azt csináltam, h bezárom a fájlt a fv végén, majd a main-ben újra megnyitom és seekelek oda ahol a stream kezdődik
most másfajta hibába ütköztem, de először megpróbálom kisakkozni a helyét..
ALI_G: nem tudom, én nem mentem bele ennyire mélyen
innen vettem a chunk-infókat, sztem megtalálod benne ami neked kell
[link] -
ALI_G
veterán
Látom wav-val szórakázol
Nekem is kellene tudni, és nemtom jól értettem-e meg a leírását. 1 dolog amiben nem vagyok biztos, mégpedig az mitől függ, hogy (kizárólag csak stereo-t nézzük) a bal és jobb csatorna hány bájtonként váltják egymást az adat mezőben? esetleg egy példát is mellékelhetsz -
STibi_
csendes tag
Kösz az ötletet, én is azt nézegettem lelkesen, hogy van-e valami használható kapcsolója a netstatnak. Mint ahogy írtam az volt a lényeg, hogy ne kelljen a (másik) monitort bámulni folyamatosan, hogy fent van-e valaki... Körbenéztem a neten, elég halott ötletek voltak, úgyhogy úgy csináltam meg, winexec-el kiküldöm 10 másodpercenként a netstat statisztikáját egy fájlba és azt nézegetem a progival. Így felcsatlakozásonként bead egy légvédelmi sziréna hangot.
Ökör egy megoldás, de a célnak megfelel. -
Jester01
veterán
Icipicit elrontottad. Elõször is betettél egy cout << ''\nloadWav OK\n''; sort a saját megtévesztésedre, mivel nem ellenõrzöd a visszatérési értéket és így akkor is OK-ot ír ha nem is ...
Másrészt a loadWav függvényben kevered az exit és a return használatát, bizonyos hibákra kilépsz másokra pedig 0-t adsz vissza.
Ugyanakkor van egy cout << ''\nftell: '' << ftell(handle); sor a loadWav végén ami nem fut le, ebbõl észrevehetted volna, hogy idõ elõtt visszatér a függvény. -
emitter
őstag
ha egy függvényen belül megnyitok egy fájl, majd a handle-jét átadom a főproginak paraméterben, az miért nem működik? hibát ad.. ez itten:
class wavInfo{
public:
...
FILE *handle;
...
};
int loadWav(char* filename, wavInfo &wi){
...
handle = fopen(filename, ''r'');
...
wi.handle = handle;
...
}
main(){
...
wavInfo *wi;
wi = new wavInfo();
loadWav(argv[1], *wi); //ez okésan lefut
cout << ''\nFilepos: '' << ftell(wi->handle); //majd erre már szegmenshibát dob
...
}
------------
lehet, h egy fv visszatérésekor bezáródik a fájl? -
emitter
őstag
-
emitter
őstag
miért van az, hogy ez a kód wav-lejátszás közben folyamatosan szaggat??
------
bufsize=44100;
buf=(short*)malloc(bufsize*sizeof(short));
while(!feof(handle)){
i = fread(buf, 1, bufsize, handle);
if(i < 0){
printf(''\nHiba fajlolvasas kozben!\n'');
exit(1);
}
printf(''\ni=%d\n'',i);
if((err = snd_pcm_writei (playback_handle, buf, bufsize)) < 0) {
fprintf (stderr, ''\nWrite to audio interface failed (%s)\n'',
snd_strerror (err));
exit (1);
}
}
-------
az, csak nem lehet az oka, hogy snd_pcm_writei() előtt van egy fread meg 2 if...
szóval mitől
ha kell, a teljes kód [link] -
csulok0000
csendes tag
-
#25954560
törölt tag
nem eleg az nvram irkalasa sajnos, mert akkor siman cat
dosemuig ertem, csak tudod a lustasag hatha csinalt mar ilyet vki. levelegtem az alaplap gyartojaval (specko cpci kartya) es ok mondtak h hasznaljam azt a bbs interface-t, kuldtek is egy dos-os .exe-t h muxik elotte persze tudtak jol h linux ala kellene, szal most ki vagyok veluk segitve.
NEM röhögünk ki senkit, ha bizonytalan vagy, privizhetsz is 
emlékeszem, régebben már kipróbáltam ezt a kiírófv-t, és ment
most már nem eszik prockót
télleg!
Ökör egy megoldás, de a célnak megfelel.
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Milyen egeret válasszak?
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- Háztartási gépek
- Medence topik
- Megújult mobilos felület, fórumos ráncfelvarrás a PROHARDVER! lapcsaládon
- Kertészet, mezőgazdaság topik
- iPhone topik
- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- Apple MacBook
- További aktív témák...
- ASUS RTX 5070 Prime OC garis
- DELL Latitude 5520 Intel Core I7-1185G7, 32 GB, 512 SSD MAGYAR VILÁGÍTÓ BILLENTYŰZET
- PlayStation Portal - Midnight Black - Garanciával
- Új ASUS RYZEN 5 7600X GAMER ERŐMŰ PC 32Gb DDR5 512GB SSD NVIDIA RTX 3070TI 8Gb DDR6 750W TÁP 2ÉV GAR
- REDRAGON K530 TKL Draconic Compact RGB Red Switch
- ÚJ/BONTATLAN Surface Pro 7+ i5-1135G7 16G 256GB 1 év garancia
- BESZÁMÍTÁS! ASUS H510M i5 11400F 16GB DDR4 500GB SSD RX 6600 8GB Rampage SHIVA FSP 500W
- Új AKRACING CORE EX gamer szék dobozában, BONTATLAN!
- BESZÁMÍTÁS! Asrock B450M R7 2700 16GB DDR4 512GB SSD GTX 1660 Super 6GB ZALMAN S4 FSP 500W
- Jó ÁRON ELADÓ! Üzleti HP Elitebook 1040 G9 4g modem! / i5-1245U 16GB 256GB FHD+
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest