Hi, I will delay including this stuff beyond the release of OSS v4.0 since it might cause some unwanted side effects.
Few comments: - IMHO the OFHOOK ioctl belongs to the pcm device instead of the mixer. - Large number of the operations performed by the mixer init function are likely to be common to all modems so they probably need to be done in hdaudio_codec.c instead. - Lack of Si3055 specific documentation should not matter. Everything should be defined in generic HDaudio documentation (see the "Codec features and requirements" section of ftp://download.intel.com/standards/hdaudio/pdf/hdaudio_03.pdf). There may be some vendor specific additions such as use of the GPIO pins to control something. Best regards, Hannju Paulo Matias wrote: > Hi, > > This is a work-in-progress patch for supporting the Si3055 HDAudio softmodem. > > It can already play and record sound from the phone line. I could > successfully dial to a phone number using a DTMF generator and talk to > people in the telephone by piping ossrecord to ossplay and vice-versa. > > I'm very grateful to Yair (cesium) and François (mmu_man), who gave a > lot of advices by IRC. > > When concluded, this code will allow for cross-platform softmodem > support. I already ported slmodem and linmodem for using OSSv4, and > François already ported linmodem for BeOS/Haiku. So slmodem will be > usable in all our x86 (because it contains some closed-source object > code) supported OSs, and linmodem (fully opensource) will be usable in > all supported platforms (although linmodem currently only supports > slowish connection speeds). An "osstelephone" tool can easily be > created too, to allow for easily using the computer as a telephone. > > However, this is just a start, and the code is extremely disorganized. > So I'm writing to ask for advice about how to improve this patch. > > Some issues remaining: > > > 1) We need a new ioctl for going Off-Hook (connected to the phone > line) and On-Hook (disconnected from the phone line). > > We discussed this in IRC and initially we though about going > off-hook/on-hook when opening/closing the device, because we didn't > see any sense in recording sound from an on-hook modem. > > However, ALSA uses a mixer control for off-hook, and NetBSD > (http://mail-index.netbsd.org/current-users/2005/04/07/0022.html) uses > a sysctl for it. > > Later, we found a reason - when pulse dialing, someone needs to > receive sound from the modem while it is on-hook, to know when the > line tone ceases. Indeed, slmodem does that. > > So we need an ioctl for going Off-Hook or On-Hook. In the patch, I > proposed the name SNDCTL_MODEM_OFFHOOK, but better names suggestions > are welcome. > > It could be implemented in hdaudio_codec_audio_ioctl(), but then > another code organization issue would arise. How to implement it > without disorganizing the code even more? > > > 2) Perhaps DUPLEX devices for modems would be better. > > By the following reasons: > > - linmodem and slmodem have code designed so that it's more adequate > to use duplex devices. > > - Two different device nodes for a modem looks somewhat cumbersome, > and has strange semantics (for example for off-hook). > > - The modem has only one sampling rate register, for both playback and > record. Let's suppose you open the recording device at 16kHz, then > forget the DTMF generator uses 8kHz and call it in the playback > device. When it sets the playback device sampling rate, the modem will > change the recoding sampling rate too, and nobody will know about > that, so messing up the recording stream. This actually happened to me > when I was testing the code. > > Using duplex devices would avoid that. > > François suggested the device nodes being named "mdm%d". It looks nice. > > Perhaps install_outputdevs() would need to be modified for using > duplex for modems, and hdaudio_endpointinfo_t would need to be > modified for being suitable for that. > > > 3) Again, code organization. How to organize this code so it doesn't > look so hackish? > > > 4) The modifications to allow mono devices in install_outputdevs() > were hackish. Maybe they could be cleaned up by solving items 2 and 3. > > A modification in hda_audio_set_channels() was needed because it was > forcing at least 2 channels. Is it OK? > > > 5) Solving stream_number issues. > > Perhaps OSS treats the stream numbers as something that needs to be > unique in the scope of a codec. For example, in attach_node(), we > have: > > endpoint->stream_number = endpoint->default_stream_number = > codec->num_inendpoints; > > So, this way, the OSS lets identical stream_numbers repeat in different > codecs. > > However, by reading the HDAudio specification, at page 17, the figure > shows that stream_numbers should be treated in the Azalia controller > scope. That is, a stream_number needs to be unique inside an entire > controller, over all of its codecs. > > In fact, if I assign stream_number=0 to the modem engine, sound > actually plays in the speaker instead of the phone line. > > I temporarily solved this by using the maximum permitted stream_number > (0xf), but this is very hackish. > > Perhaps we need a stream counter in some controller-wise struct, like > hda_devc_t or even hdaudio_mixer_t. > > Also, can I use the same stream number for the input and output > streams? It's not much clear from the specifications, but appears to > work, and OSS appears to already do this in attach_node(). > > > > Some random stuff related to this softmodem work can be found here: > http://basalto.ifsc.usp.br/~paulo_matias/modem/ > > > Please help, I still need a lot of advice on this! > > > Thanks and best regards, > > Paulo Matias > > ------------------------------------------------------------------------ > > _______________________________________________ > oss-devel mailing list > oss-devel@mailman.opensound.com > http://mailman.opensound.com/mailman/listinfo/oss-devel _______________________________________________ oss-devel mailing list oss-devel@mailman.opensound.com http://mailman.opensound.com/mailman/listinfo/oss-devel
