zu den peaks bei der auslastung:
schaut euch mal den spandsp code an, es gibt unterschiedliche "stages" beim faxempfang mit unterschiedlichen modulationen. die sind natürlich auch alle unterschiedlich rechenintensiv... das alleine würde aber noch nicht die großen ausreisser erklären.
die andere sache ist die libtiff. spandsp demoduliert, soweit gut, dann decodiert es noch das Faxprotokoll (wenn ich das richtig in erinnerung habe) und übergibt die daten an libtiff. libtiff enthält auch noch ein paar rechenintensive schritte (keine ahnung wie stark, soweit bin ich dann in die sourcen nicht vorgedrungen) wenn das tiff file abgespeichert wird. vllt. kommen daher die peaks... da ja nicht immer was gespeichert wird, bzw. das tiff codieren/kompriemieren/dekomprimieren (meist lzw oder ähnliches) auch nicht bei allen arten von daten gleich aufwendig ist.
als ich damals am faxempfang gearbeitet habe (damals noch ivcall im alten thread), habe ich oft profiling befehle in die spandsp library gesetzt um rauszufinden wie viel zeit die einzelnen teile brauchen. also einfach uhrzeit vorher und nachher messen und ergebnis ausgeben. problem hierbei: fbox hat keinen wirklich hochauflösenden timer, so dass das nicht wirklich aussagekräftig ist, wobei es eigentlich gereicht hat, weil ja gerade die rechenintensiven stellen länger gebraucht haben, so dass die auflösung gereicht hat. nur weiter ins detail gehen wurde schwer... also so als kleine anregung. vielleicht hat ja jetzt jemand mehr erfolg bei der suche als ich damals
PS: Zum Thema "fixed-point" ... seit ihr sicher, dass wenn spandsp mit fixed-point kompiliert wird, dann auch wirklich der softmodem teil damit gebaut wird? In der Version, die ich verwendet hatte, war fixed poiint support nur für diverse andere emulationen implementiert, NICHT jedoch für das V.29 (??) oder eben das was für Faxe verwendet wird! Deswegen habe ich ja begonnen die fastfp library zu schreiben, mit dem ziel ohne große spandsp änderungen das ding mal mit festkomma zahlen arbeiten zu lassen. das problem ist nur, dass das so nicht möglich ist, weil ein algo. der auf gleitkomma ausgelegt ist, einfach mal nicht einfach so mit festkomma arbeitet ohne am algorithmus änderungen vorzunehemen. machbar sollte es aber sein... das schwierige ist hier zu wissen in welchem bereich sich die variablen befinden können und sie dementsprechend zu skalieren........ dazu müsste man schon sehr gut vertraut mit der modulation sein und den spandsp code sehr gut kennen
PPS: Zu Frameslips... so wie ich das im spandsp faq gesehen hab, ist das der fall wenn sender und empfänger um ein einziges sample auseinander sind? wenn es denn so wäre, dann könnten wir da aber gar nichts dagegen tun (zumindest auf direktem wege). wenn uns ein sample fehlt, dann liegt das erstmal am capi, dass uns eines zu wenig liefert. sollte aber doch nicht vorkommen, da die daten ja digital vom isdn netz kommen und nicht mehr gesampelt werden müssen (denn sonst könnte es ja zu einem clockdrift kommen). was im spandsp faq steht (link von bodega), mit timing problemen bezieht sich nur auf das telefonnetz und zwar wenn zwischen analog und digital konvertiert wird. solange wir die daten nur digital von einer fbox zur anderen übertragen, über ein deutsches netz, dann sollte es vom netz keine frame-slips geben. es liegt somit alles an der box und den programmen.
