> > For flexibility you need to allow for 8bit samples being converted as: > > 1) 8bit raw ulaw or alaw data (unchanged from line). > > 2) 8bit raw data, bit reversed, any hdlc protocol > > is bit reversed from audio [1]. > > 3) 8bit audio, converted from alaw to ulaw > > 4) 8bit audio, converted from ulaw to alaw > > 5) 16bit linear converted to/from alaw or ulaw and on a per-timeslot > > basis. > I agree. That we only support very limited samples. But We can add this > in second step once the basic framework is in. > Also right now the testing infrastructure we have, we won't be able to > test all these scenarios.
You probably ought to make the application request a specific format - and error the unsupported ones. That would make it easier to add support for other formats later. I also suspect that this 'framework' isn't that general! We (as a company) use the TDM interface blocks on the MSC8101 and MSC8013 Starecore DSPs as well as some bespoke FPGA logic (which will do ulaw<->alaw convertion). The 'framework' would almost certainly be inappropriate for both out hardware and software. David _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev