Optymalne metody kompresji audio w 2kBps: GSM, ADPCM i ich wyzwania
O kompresji audio...
From: Jelo <env_at_nospam_poczta.onet.pl>
Subject: O kompresji audio...
Date: Tue, 24 Sep 2002 23:08:24 +0200
Witam,
Coś już o tym zacząłem, ale to było dawno i w wątku nie na temat...
Potrzebuje przepchnąć gadkę (zrozumiale) przez kanał o średnicy 2kBps.
GSM codec byłby znakomity, jako że ciągnie 1625Bps (podobno), też ktoś
mi pisał, że toto niby "łatwe" jest. Gdzieś na www znalazłem, że to
wymaga szybkiego 486 przynajmniej - lub czegoś porównywalnego DSP...
Dysponując 8-bitową mocą obliczeniową AVRa można podjąć takie wyzwanie
;)))
Pozostaje chyba tylko ADPCM? Hmm...
Jeden grupowy expert :)) (J.F.) napisał mi mniej więcej dokładnie to:
*
dajesz np dwa bity na probke, i jesli poprzednia powodowala
wzrost, to teraz kodujesz:
00 - +0
01 - +1
10 - -1
11 - +3
A jesli poprzedno byl spadek, to wykonujesz -3 zamiast +3.
*
[opcjonalnie +/-5]
Mam pytanie do experta :) - bo to chyba tak nie za bardzo będzie
działać... nagrałem sobie kawałek gadki na wav'a, znalazłem bardziej
agresywny kawałek - i zobaczcie sami:
www.takietam.prv.pl/chwila/wav.gif (mowa, 8kHz, 8-bit, unsigned)
różnice m-dzy 2 próbkami w niektórych miejscach dochodzą do 50!
To zanim - stosując 2bitowy (+5) ADPCM - by to narosło, to już by się
górka 3x zdążyła skończyć!
A może można tak zrobić, żeby na 2 bitach zapisywać o ile ma się
zwiększyć przyspieszenie następnej próbki - czyli
stosując +5 po 5 próbkach mamy przyrost 25...
- to by może i nawet mogło mieć jakiś sens (patrz kształt sinusa)
ale obawiam się że w rezultacie by powstał taki filtr
dolnoprzepustowy, że lepiej od razu użyć ADPCMa na 4 bitach?
Czyż nie? :)
Nie mówiąc już o praktycznej stronie zrealizowania takiego czegoś,
gdzie trzeba by badać próbki nie tylko poprzedzające, ale i te co są
później... 5-10 próbek później (podczas kodowania)
[ADPCM 4bit]
Zakładam sobie że ramka ma np 65bajtów - na przykład.
Pierwszy bajt, to "zwykłe 8bit" określające pozycje startową ramki,
a później już leci... (4bit=16 różnych wartości zmian)
0001 - +1
(...)
0100 - +15
(...)
0111 - +50 to tak np. nie wiem jak to dobrze dobrać jeszcze...
1001 - -1
...
1111 - -50
Dobrze by to było? :)
Oczywiście podczas kodowania jest porównywana wartość uzyskana - tak
jak by to było dekodowane - z rzeczywistą...
Wynikało by z tego, że 16bit da się ADPCMem zakodować 1:4, a 8 - 1:2
Z tym, że... te 16bit to i tak słychać gorzej niż "zwykłe" 8.
AHA - i pytanie z innej beczki, zupełnie przy okazji :)
Czy można TRAFO (12V ok 100W) zasilać szczątkami sinusoidy - regulator
na triaku? Czy konieczny byłby jakiś BUZ już na wyjściu?
TRAFO ma zasilać tylko i wyłącznie elektromagnes (taki od rozrusznika)
- on nie może dostać od razu full mocy, tylko musi stopniowo...
[w ramach ciekawostki]
Robiłem testy - ten elektromagnes od rozrusznika musi być zasilany
stałym napięciem.
Na zmiennym działał tak samo jak na "stałym" (bez kondensatora) -
wydajność około 30% - dopiero naprawde "stałe" napięcie mu służy...
Pozdrawiam,
jelo
From: Tadeusz Gozdek <taddy_at_nospam_sys.net.pl>
Subject: Re: O kompresji audio...
Date: Wed, 25 Sep 2002 01:11:12 +0200
Jelo wrote:
GSM codec byłby znakomity, jako że ciągnie 1625Bps (podobno), też ktoś
mi pisał, że toto niby "łatwe" jest. Gdzieś na www znalazłem, że to
wymaga szybkiego 486 przynajmniej - lub czegoś porównywalnego DSP...
Dysponując 8-bitową mocą obliczeniową AVRa można podjąć takie wyzwanie
;)))
No coz. Byli juz tacy co mowili, ze wepchna to w AVRka ale jakos
po kilku probach porzucali projekt tlumaczac sie brakiem czasu itp....
Moim zdaniem albo zastosuj specjalizowany uklad sprzetowego kodeka
tak jak to sie zwyklo ostatnio robic w fabrycznych urzadzeniach albo daj
cos
co sobie poradzi z ta iloscia obliczen. Pewnie jakis szybki 32-bitowy
procek z dodatkowa jednostka arytmetyczna by sobie jaks poradzil
a jak nie to po prostu lepszy DSP. Tylko czy to w Twoim przypadku bedzie
mialo sens ?
Pozostaje chyba tylko ADPCM? Hmm...
ADPCM-em jestes w stanie "sciac" pasmo do 16kbit co jest wynikiem
prawie odpowiadajacym Twoim wymaganiom bo dojdzie pewien drobny narzut.
Nie wymaga tez koszmarnej mocy obliczeniowej. Tylko niestety jakosc
nie dorownuje kodekom klasy CELP (przy tym samym generowanym strumieniu
wyj.).
Dla zainteresowanych chyba mam gdzies gotowe procedurki w C
dla kodekow G.711,721,723 i chyba 726 oraz jakies opisy i chyba
zrodla CELPow itp. tych bardziej zaawansowanych kodekow.
Ostatecznie przeciez zawsze mozna to skompilowac i samemu zobaczyc jak
sie zachowuje w danym procku :-)
Jeden grupowy expert :)) (J.F.) napisał mi mniej więcej dokładnie to:
No coz skoro napisal to bez sensu byloby sie powtarzac.
Mam pytanie do experta :) - bo to chyba tak nie za bardzo będzie
działać... nagrałem sobie kawałek gadki na wav'a, znalazłem bardziej
agresywny kawałek - i zobaczcie sami:
www.takietam.prv.pl/chwila/wav.gif (mowa, 8kHz, 8-bit, unsigned)
różnice m-dzy 2 próbkami w niektórych miejscach dochodzą do 50!
To zanim - stosując 2bitowy (+5) ADPCM - by to narosło, to już by się
górka 3x zdążyła skończyć!
Dostaniesz po prostu troche obciete pasmo (swojego rodzaju filtr
dolnoprzepustowy).
Da sie to troszke odreperowac roznymi metodami ale w sumie nie wiem czy
jest sens.
Tak prostymi metodami nie wygenerujesz niestety znaczacej a moze i wrecz
zauwazalnej
poprawy dzwieku. Zreszta ADPCM czyli zdajesie G.723/G.726 to kompresja
stratna wiec chyba nie ma sie czemu dziwic, ze po zdekodowaniu sygnal
jest "gorszy" niz oryginal.
A co do kodowania probek z/na 16/8 bitow - to do upchania/przywrocenia
stosuje sie kompresje z serii u-law i A-law zwane bodajze G.711
Uproszczony opis ich dzialania:
- linear2alaw() - Convert a 16-bit linear PCM value to 8-bit A-law
*
* linear2alaw() accepts an 16-bit integer and encodes it as A-law data.
*
* Linear Input Code Compressed Code
* ------------------------ ---------------
* 0000000wxyza 000wxyz
* 0000001wxyza 001wxyz
* 000001wxyzab 010wxyz
* 00001wxyzabc 011wxyz
* 0001wxyzabcd 100wxyz
* 001wxyzabcde 101wxyz
* 01wxyzabcdef 110wxyz
* 1wxyzabcdefg 111wxyz
oraz to
- linear2ulaw() - Convert a linear PCM value to u-law
*
* In order to simplify the encoding process, the original linear
magnitude
* is biased by adding 33 which shifts the encoding range from (0 -
8158) to
* (33 - 8191). The result can be seen in the following encoding table:
*
* Biased Linear Input Code Compressed Code
* ------------------------ ---------------
* 00000001wxyza 000wxyz
* 0000001wxyzab 001wxyz
* 000001wxyzabc 010wxyz
* 00001wxyzabcd 011wxyz
* 0001wxyzabcde 100wxyz
* 001wxyzabcdef 101wxyz
* 01wxyzabcdefg 110wxyz
* 1wxyzabcdefgh 111wxyz
*
* Each biased linear code has a leading 1 which identifies the segment
* number. The value of the segment number is equal to 7 minus the
number
* of leading 0's. The quantization interval is directly available as
the
* four bits wxyz. * The trailing bits (a - h) are ignored.
--
Pozdrawiam
Tadeusz Gozdek (Taddy) Network manager [TG2442-RIPE] Gadu-gadu: 2919
--------------------------------------------------------------------
Chcesz sterowac urzadzeniami przez LAN lub Internet? Plytka z AT89C52
i kontrolerem ethernetu RTL8019
http://www.allegro.pl/showitem.php?item=7447099
Cos na czesci http://www.allegro.pl/showitem.php?item=7372136
From: "Tomasz Sawicki" <kotburak_at_nospam_poczta.onet.pl>
Subject: Re: O kompresji audio...
Date: Fri, 27 Sep 2002 22:54:10 +0200
Potrzebuje przepchnąć gadkę (zrozumiale) przez kanał o średnicy 2kBps.
GSM codec byłby znakomity, jako że ciągnie 1625Bps (podobno), też ktoś
mi pisał, że toto niby "łatwe" jest. Gdzieś na www znalazłem, że to
wymaga szybkiego 486 przynajmniej - lub czegoś porównywalnego DSP...
Dysponując 8-bitową mocą obliczeniową AVRa można podjąć takie wyzwanie
;)))
GSM byłby dobry - daje strumień 13kb/s, czyli 33 bajty co 20ms. Jakość na
8kHZ jest dobra, na 16kHz nawet bardzo dobra.
Jeszcze lepszy jest podobno AMR zastosowany też w komórkach w EFR, ale
potrzebuje więcej mocy obliczeniowej, a daje troche mniejszy strumień, przy
lepszej jakości.
A czemu akurat piszesz o AVR?
Gdyby ten procek jeszcze był 16 bitowy... To przy jakiś kilkunastu MIPSach
powinno pójść. Tylko te 8 bitów...
Niestety kompresja GSM operuje na danych 16 (a dokładnie 13-bitowych) więc
dla 8 bitowego procesora to lekka makabra.
A przemyśl taką opcję: ADSP-2195 + AD73311 + jakiś flash + jakieś dodatki =
całość powinna się zamknąć (100-150)PLN nawet w detalu, wliczając płytkę.
Dopiąć do tego można co chcesz, peryferiów też ma troche, darmowe środowisko
uruchomieniowe (no prawie), a pociągnie nawet 16 kanałów na raz
kompresja/dekompresja GSM :)) Wiem, że to może troche za dużo, ale uwierz mi
ten DSP (160 MIPS) jest tańszy niż tej samej firmy 33MIPS.
Pzdr,
Tomasz Sawicki
From: Jelo <env_at_nospam_poczta.onet.pl>
Subject: Re: O kompresji audio...
Date: Sat, 28 Sep 2002 03:08:22 +0200
witaj!
A czemu akurat piszesz o AVR?
no właśnie - czemu, bo to nie miała być żadna armata, tylko "telefony"
takie żeby jak najtaniej to wyszło, a żeby się dało gadać, i żeby dane
szły po jednej lini, na której jest zapiętych X userów!
AVRy 8535 mają nawet akurat przetwornik A/D co prawda żółw straszny,
ale do tego akurat wystarczy... i ot co,
Heh, myślę, że jak się za to w końcu zabiorę, a bo jeszcze coś muszę
po drodze zrobić, za co też się nie mogę zabrać (brak chęci),
to tamto na jakimś ADPCM-like codeku :))) - najprościej,
najszybciej...
[Adaptacja GSMa dla AVR]
A go aby nie można "ściąć" do tych 8bitów? Czy on później liczy na 13,
a przetworniki są i tak 8?
To znaczy - tu chyba nie o same 8, czy 16 bit chodzi, jak robić
cokolwiek bardziej zaawansowanego - sygnałowego - na procesorze, który
8bit mnożenie robi programowo w jakoś 50 cyklach (IIRC) :))
A przemyśl taką opcję: ADSP-2195 + AD73311 + jakiś flash + jakieś dodatki =
(...)
ten DSP (160 MIPS) jest tańszy niż tej samej firmy 33MIPS.
jeśli wolna spytać :)
Co to za cudo jest? - kto to produkuje?
Ten DSP - jest to w jakiś "normalnych" obudowach?
Bo nie za bardzo mam ochotę i zdolności się lutować z czymś powyżej
PLCC... ile to kosztuje mniej więcej?
On chyba przebija słynne TMS320c25?/pochodne?
ten AD73311 - to zwykły A/D tak? 13bit? 8kHz 1kanał?
pozdr,
jelo
From: "Tomasz Sawicki" <kotburak_at_nospam_poczta.onet.pl>
Subject: Re: O kompresji audio...
Date: Sat, 28 Sep 2002 09:42:17 +0200
no właśnie - czemu, bo to nie miała być żadna armata, tylko "telefony"
takie żeby jak najtaniej to wyszło, a żeby się dało gadać, i żeby dane
szły po jednej lini, na której jest zapiętych X userów!
A to nie lepiej zrobić to np. na Ethernecie? Jakiś Realtek 8219 (nie jestem
pewny numeru) - dałoby to 10Mb/s czyli teoretycznie ponad 1MB/s, nie
potrzebujesz kompresji, może nawet AVRek dałby radę :)
AVRy 8535 mają nawet akurat przetwornik A/D co prawda żółw straszny,
ale do tego akurat wystarczy... i ot co,
Heh, myślę, że jak się za to w końcu zabiorę, a bo jeszcze coś muszę
po drodze zrobić, za co też się nie mogę zabrać (brak chęci),
to tamto na jakimś ADPCM-like codeku :))) - najprościej,
najszybciej...
Ja w swoim urządzeniu miałem robić ADPCM, ale doszedłem do wniosku, że
stosunek (potrzebna moc/efekty(przepustowość)) jest o wiele gorszy niz w
przypadku GSM
[Adaptacja GSMa dla AVR]
A go aby nie można "ściąć" do tych 8bitów? Czy on później liczy na 13,
a przetworniki są i tak 8?
To znaczy - tu chyba nie o same 8, czy 16 bit chodzi, jak robić
cokolwiek bardziej zaawansowanego - sygnałowego - na procesorze, który
8bit mnożenie robi programowo w jakoś 50 cyklach (IIRC) :))
no teoretycznie wszystko można zrobić, ściąć do 8 bitów też, tylko spadnie
jakość, chociaż z tymi 50 cyklami to byłby duży problem.
A przemyśl taką opcję: ADSP-2195 + AD73311 + jakiś flash + jakieś dodatki
=
(...)
ten DSP (160 MIPS) jest tańszy niż tej samej firmy 33MIPS.
jeśli wolna spytać :)
Co to za cudo jest? - kto to produkuje?
Żadne cudo - normalny stałoprzecinkowy 16-bitowy DSP Analog Devices,
mnożenie + dodawanie + pobranie 2 danych z pamięci w jednym cyklu (6,25 ns).
Z tym że IMO nadaje się też do innych zastosowań nie związanych ściśle z
przetwarzaniem sygnałów (w przeciwieństwie np do DSP Motoroli) np. jakieś
szybkie sterowanie, obsługa jakiegoś USB na przerwaniach itp.
Ten DSP - jest to w jakiś "normalnych" obudowach?
Normalna dla takich scalaków PQFP144, ewentualnie jakieś pBGA.
Bo nie za bardzo mam ochotę i zdolności się lutować z czymś powyżej
To może Ci to przylutować ktoś kto ma zdolności i sprzęt, np. poważny serwis
tel.kom.
PLCC... ile to kosztuje mniej więcej?
Porównując do AVR, kupowałem kiedyś 8515 najtaniej za 40PLN w detalu, ten
DSP (2195) w hurcie powinien kosztować podobne pieniądze, w detalu? 2 razy
więcej? Ja używam 2191, który ma więcej pamięci (po 32kB program/data) i
kosztuje około $16 w małym hurcie.
On chyba przebija słynne TMS320c25?/pochodne?
Akurat Texasa nie znam, ale porównująć 219x do poprzedniej generacji
Analoga - 218x to niebo i ziemia, właśnie o 2181(33MIPS) pisałem że jest
droższy od 2195 (nie wiadomo dlaczego).
Wszystkie DSP (AD,TI, czy Motorola) sa podobne, liczy się tylko zegar i
elastyczność podłączania peryferiów, pamięci itp. Jest jeszcze jedno -
assembler AD jest bardzo naturalny, nie ma mnemoników, jak w Moto, czy TI,
więc bardzo szybko się go uczysz. Ja chyba właśnie dlatego wybrałem AD. No i
oczywiście jest C/C++ i dają też jakiś RTOS.
ten AD73311 - to zwykły A/D tak? 13bit? 8kHz 1kanał?
Też Analog Devices, kodek audio, próbkowanie 8,16,32,64 kHz, lub inne
(zależy jakie kwarce przypniesz) interface szeregowy.
Pzdr,
TS
From: Jelo <env_at_nospam_poczta.onet.pl>
Subject: Re: O kompresji audio...
Date: Sat, 28 Sep 2002 20:22:59 +0200
A to nie lepiej zrobić to np. na Ethernecie? Jakiś Realtek 8219 (nie jestem
pewny numeru) - dałoby to 10Mb/s czyli teoretycznie ponad 1MB/s, nie
potrzebujesz kompresji, może nawet AVRek dałby radę :)
Ethernet - nie... juz mamy siec na BNC, a tak ciaglosc lini + drogie
kable, na UTP znowu hub'y, i tez kable drogie, i jeszcze wsyztskie w
jedno miejsce...
ale tak pozatym, ten Realtek 8219 (ja tym bardziej numerkow nie znam),
to jest tylko sterownik lini (UTP/?), czy to caly sterownik, z buforem
i caly pakiet pamieta... latwo jest toto obslugiwac?
Znajomy cos wmymyslal, zeby Z180 :) wpiac do interneta,
i wlasnie albo te realteki jakos... ale on raczej myslal, zeby
sieciowke isa nie p'n'p do tego zatrudnic...
...ale to chyba nie takie proste TCP/IP / cala reszta...
Ja w swoim urządzeniu miałem robić ADPCM, ale doszedłem do wniosku, że
stosunek (potrzebna moc/efekty(przepustowość)) jest o wiele gorszy niz w
przypadku GSM
no fakt - GSM daje dobrze rade...
a takie pytanie - w jaki sposób GSMy robią FULL/HALF RATE?
(w czym różnica? - oba są 8kHz chyba tak?)
HALF rate to jest 1625 bajtow/s, czy to jest polowa z tego...
o ile mi wiadomo, to wsyzstkie sieci, poza IDEĄ na half chodzą...
[Adaptacja GSMa dla AVR]
no teoretycznie wszystko można zrobić, ściąć do 8 bitów też, tylko spadnie
jakość, chociaż z tymi 50 cyklami to byłby duży problem.
Hmm... ale ten GSM, to coś tak lekko w deseń layer3 wpada chyba?
Bo na jakiej to zasadzie ten dzwiek kompresuje - na czym sama idea
polega, szukałem po internetach, ale tam nic co by tłumaczyło jak to
działa nie znalazłem - inna sprawa że modemowe szukanie to...
[ADSP-2195]
...heh, no to się tym chyba będe musiał zainteresować.
a masz może pdf'a? jak toto nie za wiele zajmuje - mógłbyś na _at_nospam_
podesłać, jak nie - to sobie na AD poszukam u kogoś...
[AD73311]
A dla czego on akurat? Maxim f.e. też dużo fajnych przetworników ma w
ofercie - i free sample...
Analog też jakieś free sample miał... coś tak słyszałem...
Inna sprawa, czy te DSP mają jakieś praktyczne wykożystanie
w polskiej rzeczywistości?
pozdrawiam,
jelo
From: "jerry1111" <jerry1111_at_nospam_wp.pl>
Subject: Re: O kompresji audio...
Date: Sat, 28 Sep 2002 20:42:37 +0200
ale tak pozatym, ten Realtek 8219 (ja tym bardziej numerkow nie znam),
to jest tylko sterownik lini (UTP/?), czy to caly sterownik, z buforem
i caly pakiet pamieta... latwo jest toto obslugiwac?
Znajomy cos wmymyslal, zeby Z180 :) wpiac do interneta,
i wlasnie albo te realteki jakos... ale on raczej myslal, zeby
sieciowke isa nie p'n'p do tego zatrudnic...
...ale to chyba nie takie proste TCP/IP / cala reszta...
RTL8019AS - zwykly 'podlaczany' do ISA
To kompletny sterownik do ethernetu - wpisujesz mu
jego MAC address i odbiera tylko do niego adresowane pakiety.
Bardzo prosta aplikacja (RTL + trafo do skretki + RJ ;)
A same tcp jako takie tez nie trudne. Zalozysz sobie brak
fragmentacji pakietow, albo dopuscisz tylko 2 fragmenty
i wychodzi dosc prosto. Problem sie robi jak jest duzy przeplyw
danych do procka i duzo przychodzi fragmentow pakietow, wtedy
trzeba nagle kombinowac na siakis bufor pamiec i mechanizm zarzadzajacy,
ale to juz OT
jerry
PS: Jeszcze sie nie spotkalem zeby byla potrzebna fragmentacja
pakietow, a jak robilem experymenty, to Intel 8100FR chyba (bo juz nie
pamietam) nie przepuszczal w swiat pocietych ramek.
From: jfox_at_nospam_poczta.onet.pl (J.F.)
Subject: Re: O kompresji audio...
Date: Sun, 29 Sep 2002 11:27:32 GMT
On Sat, 28 Sep 2002 20:42:37 +0200, jerry1111 wrote:
PS: Jeszcze sie nie spotkalem zeby byla potrzebna fragmentacja
pakietow, a jak robilem experymenty, to Intel 8100FR chyba (bo juz nie
pamietam) nie przepuszczal w swiat pocietych ramek.
Fragmentacja pakietow jest niemal obowiazkowa - IP jej wymaga.
Jesli laczysz sie ze swiatem, to nie wiesz czy po drodze od
klienta nie ma routera ktory pakiet potnie - a kazdy ma prawo.
To co piszesz o 8100 mnie troche dziwi ... sam kiedys takowy mialem
i problemow sobie nie przypominam, ale fragmentacji nie sprawdzalem..
J.
From: "jerry1111" <jerry1111_at_nospam_wp.pl>
Subject: Re: O kompresji audio...
Date: Sun, 29 Sep 2002 17:08:19 +0200
Fragmentacja pakietow jest niemal obowiazkowa - IP jej wymaga.
Jesli laczysz sie ze swiatem, to nie wiesz czy po drodze od
klienta nie ma routera ktory pakiet potnie - a kazdy ma prawo.
To co piszesz o 8100 mnie troche dziwi ... sam kiedys takowy mialem
i problemow sobie nie przypominam, ale fragmentacji nie sprawdzalem..
Po prostu fragmentacja nie jest uzywana (IMHO), bo wyobraz
sobie routerek na skromne 10Mbit. Jak lacze jest zapchane
i WSZYSTKIE albo tylko polowa pakietow przyjdzie pocieta, to
co wtedy? Poza tym nie wiesz w jakiej kolejnosci one dotra. Moga
rownie dobrze isc od ostatniego do pierwszego!
Gigabajt ramu na bufor do pakietow? A algorytmy
zarzadzania i laczenia fragmentow. Moj stos obsluguje tylko
2 fragmenty ale i tak nie zanotowalem zeby kiedykolwiek bylo to
potrzebne. Swoja droga moze sa tu lepsze spece od tego tematu (bo
ja to skromny zuczek) i sie wypowiedza w temacie.
jerry
From: jfox_at_nospam_poczta.onet.pl (J.F.)
Subject: Re: O kompresji audio...
Date: Sun, 29 Sep 2002 11:27:34 GMT
On Sat, 28 Sep 2002 20:22:59 +0200, Jelo wrote:
ale tak pozatym, ten Realtek 8219 (ja tym bardziej numerkow nie znam),
to jest tylko sterownik lini (UTP/?), czy to caly sterownik, z buforem
i caly pakiet pamieta... latwo jest toto obslugiwac?
8129. Zaraz - a moze 8019/8029 ?
To jest karta NE2000 ISA w jednej kosci - wersja AS ma nawet pamiec
w chipie. Obsluga jedna z najprostszych, tylko trzeba sygnaly
magistrali ISA wygenerowac - w zakresie zapis/odczyt portu.
Nie jestem pewien czy trzeba 16 bit - kiedy jedna ne2000
wsadzilem w XT w slot 8 bit i dzialalo, ale to nie byla kostka 8029.
Natomiast 8129 ... cos mi sie kojarzy ze to PCI ..
Znajomy cos wmymyslal, zeby Z180 :) wpiac do interneta,
i wlasnie albo te realteki jakos... ale on raczej myslal, zeby
sieciowke isa nie p'n'p do tego zatrudnic...
Tez dobry pomysl. Tylko jeden problem - karty ISA to juz wylacznie
z drugiego obiegu [8019/29 chyba tez]
p'n'p po ISA nawiasem mowiac nie jest takie trudne ..
...ale to chyba nie takie proste TCP/IP / cala reszta...
kawalek softu potrzebny, nie da sie ukryc.
Inna sprawa, czy te DSP mają jakieś praktyczne wykożystanie
w polskiej rzeczywistości?
Kiepskie, ale kiedys trzeba zaczac, nieprawdaz ? :-)
J.
From: "jerry1111" <jerry1111_at_nospam_wp.pl>
Subject: Re: O kompresji audio...
Date: Sun, 29 Sep 2002 17:09:00 +0200
8129. Zaraz - a moze 8019/8029 ?
To jest karta NE2000 ISA w jednej kosci - wersja AS ma nawet pamiec
w chipie. Obsluga jedna z najprostszych, tylko trzeba sygnaly
magistrali ISA wygenerowac - w zakresie zapis/odczyt portu.
Nie jestem pewien czy trzeba 16 bit - kiedy jedna ne2000
wsadzilem w XT w slot 8 bit i dzialalo, ale to nie byla kostka 8029.
8029AS dziala na 8bit
jerry
From: "Tomasz Sawicki" <kotburak_at_nospam_poczta.onet.pl>
Subject: Re: O kompresji audio...
Date: Sun, 29 Sep 2002 23:09:49 +0200
a takie pytanie - w jaki sposób GSMy robią FULL/HALF RATE?
(w czym różnica? - oba są 8kHz chyba tak?)
HALF rate to jest 1625 bajtow/s, czy to jest polowa z tego...
o ile mi wiadomo, to wsyzstkie sieci, poza IDEĄ na half chodzą...
Z tego co wiem to HR ma po prostu inny algorytm dający mniejszy strumień,
ale mogę się mylić. Nigdy nie robiłem HRa bo i po co?
FR jest akurat. Kiedyś może zrobię EFR, ale to już na pewno jest inny
algorytm (AMR) i nie wiem czy będzie potrzeba (zamówienie).
Jeśli chcesz o tym poczytać to specyfikacje są dostępne free na www.etsi.org
i trzeba poszukać np 06.10 -< GSM, 06.32 Voice Activity Detection i inne. Są
też szczegółóowe algorytmy w psudokodzie.
[Adaptacja GSMa dla AVR]
no teoretycznie wszystko można zrobić, ściąć do 8 bitów też, tylko
spadnie
jakość, chociaż z tymi 50 cyklami to byłby duży problem.
Hmm... ale ten GSM, to coś tak lekko w deseń layer3 wpada chyba?
Heh kompresja MPEG1 Layer 3 jest o wiele bardziej złożona, w moim przypadku
były takie propozycje coby MP3 zaimplementować, ale odpuściłem, prawdę
mówiąc nie wiem czy ten 160 MIPS DSP by sobie poradził w realtime z jednym
kanałem, a GSM robi spokojnie 16 na raz.
Bo na jakiej to zasadzie ten dzwiek kompresuje - na czym sama idea
polega, szukałem po internetach, ale tam nic co by tłumaczyło jak to
działa nie znalazłem - inna sprawa że modemowe szukanie to...
Więc tak w skrócie: GSM 06.10 to zmodyfikowana wersja LPC (Linear
Predicitive Coder). Używa on uproszczonego modelu ludzkich dróg głosowych,
który składa się z serii cylindrów różniących się średnicą. Aby wyprodukować
głos należy przepuścić powietrze przez te cylindry (taka seria piszczałek).
Aby poprawić jakość (wczesne systemy LPC pozwalały zrozumieć mowę, ale nie
np. odróznić rozmówcy) zastosowano dodatkowo 2 techniki: RPE (Regular Pulse
Excitation) i LTP (Long Term Prediction). Dokładne podstawy teoretyczne są w
specyfikacji.
Rzeczywiście czasami na krótko głos jest bardzo podobny do piszczałki - taki
śpiewny, ale przy 16kHz jest super. W telefonach dodali do tego na pewno
jeszcze jakieś filtry dolnoprzepustowe, bo kodowanie słychać dopiero jak się
transmisja rwie.
[ADSP-2195]
...heh, no to się tym chyba będe musiał zainteresować.
a masz może pdf'a? jak toto nie za wiele zajmuje - mógłbyś na _at_nospam_
podesłać, jak nie - to sobie na AD poszukam u kogoś...
Mogę Ci podesłać, tylko że to waży ok. 5MB Hardware manual, plus do tego
Instruction Set i inne.
[AD73311]
A dla czego on akurat? Maxim f.e. też dużo fajnych przetworników ma w
ofercie - i free sample...
Tak wyszło (promocja AD czy coś) - Maxim był droższy, poza tym ten ma
przedwzmacniacze, filtry itp.
Ten kodek ma tą przewagę nad innymi np. zgodnymi z AC97, że można go ustawić
tak że w streamie idą same dane próbek. Pozwala to np. ustawić DMA na
pobranie 160 sampli i dostajesz przerwanie co 20ms i już. Natomiast kodeki
AC97 (których bardzo nie lubię) wymagają przesyłania danych sterujących w
streamie (w każdym okresie), a przez to musisz mieć przerwanie co każdą
próbkę (okres). Wprowadza do dodatkowy overhead w kodzie - dodatkowe (około
100 *159) niepotrzebnych cykli żeby tylko obsłużyć transmisję.
A i jeszcze jedno, można ich połączyć do 8 w kaskadzie beż żadnych
dodatkowych elementów. A gdybym się uparł to 128. Wyobraż sobie 128 kanałów
audio full duplex w jednym scalaku :)
Analog też jakieś free sample miał... coś tak słyszałem...
Inna sprawa, czy te DSP mają jakieś praktyczne wykożystanie
w polskiej rzeczywistości?
Jak je sobie zastosujesz to mają :) W końcu również i Ty kreujesz
rzeczywistość :)
pozdrawiam,
jelo
Pzdr,
TS
From: Adam Dybkowski <adybkows_at_nospam_amwaw.edu.pl>
Subject: Re: O kompresji audio...
Date: Sun, 29 Sep 2002 00:03:50 +0200
Tomasz Sawicki wrote:
no właśnie - czemu, bo to nie miała być żadna armata, tylko "telefony"
takie żeby jak najtaniej to wyszło, a żeby się dało gadać, i żeby dane
szły po jednej lini, na której jest zapiętych X userów!
A to nie lepiej zrobić to np. na Ethernecie? Jakiś Realtek 8219 (nie jestem
pewny numeru) - dałoby to 10Mb/s czyli teoretycznie ponad 1MB/s, nie
potrzebujesz kompresji, może nawet AVRek dałby radę :)
Ja w ramach pracy magisterskiej zrobilem wlasnie telefon IP dzialajacy w
sieci Ethernet, oparty na 20-MIPSowych procesorze DSP i Ethernetowym
scalaku CS8900A (bardzo podobny w programowaniu do innych przeznaczonych
dla magistrali ISA):
http://www.amwaw.edu.pl/~adybkows/telefonip/front.html
--
Adam Dybkowski
adybkows_at_nospam_amwaw.edu.pl
http://www.amwaw.edu.pl/~adybkows