Au600
From the ALSA wiki
Jump to: navigation, search
Contents
AU600
the au600 device is a usb PSTN gateway that allows using a plain old telephone as VoIP phone.
This driver got reverse engineered, so not everything might work as expected yet.
Current developer: Markus Rechberger \<mrechberger|at|gmail.com>
IRC on freenode: mrec/mrec_
Hardware
Supported:
- ATCom AU600 http://www.packetizer.com/products/au600/
- ASound TLink http://www.asound.com/ProductDetails.asp?ProductClass=68&ID=290
Probably supported:
- USRobotics USR9620 http://www.usr.com/products/voip/voip-product.asp?sku=USR9620
OEM Page:
- SmLink "Personal Gateway" http://www.smlink.com/emall/content.asp?cc=66996&id=49031&fid=7254
A note on phone suport: Referencing http://www.epanorama.net/circuits/telephone_ringer.html on data on what to expect from an FXS line:
"In USA minimum ring voltage supplied is 40Vrms (delivered into a 5 REN load)."
Using a multimeter, I got about 45VAC for the ringer voltage. The manual for the Asound TLink says it will support up to 5 phones which would indicate a REN of 5. The USR says 3 as does the AU600. In any case, I had a great deal of difficulty finding phones that would ring with the adapter. I think that this device cannot quite push enough current to ring some non-european phones or is otherwise out of spec.
Bugreports
http://bugzilla.kernel.org/show_bug.cgi?id=7134
Progress
Tue Okt 3 19:20:49 CEST 2006
small cleanup, the driver will only create one device instead of 2 from now on. Also adjusted the .asoundrc file below
So Aug 20 15:44:49 CEST 2006
Since I'd like to get that device work with asterisk some more work is needed.. after modifying chan_alsa.c (which is part of the asterisk project), asterisk starts to detect inband DTMF tones..
Detected inband DTMF digit: 0 on ALSA
Detected inband DTMF digit: 0 on ALSA
Detected inband DTMF digit: 4 on ALSA
Detected inband DTMF digit: 3 on ALSA
Detected inband DTMF digit: 3 on ALSA
Detected inband DTMF digit: 3 on ALSA
Detected inband DTMF digit: 3 on ALSA
Detected inband DTMF digit: 6 on ALSA
Detected inband DTMF digit: * on ALSA
Detected inband DTMF digit: * on ALSA
Detected inband DTMF digit: * on ALSA
Detected inband DTMF digit: * on ALSA
since this device only works with 9600 hz you might have some problems to play other files with a different sample rate.. alsa is capable of converting and multiplexing different streams. Here's an example that can be used for playback:
aplay -D plug:duplex <filename>
pcm.au600playback {
type dmix
ipc_key 1024
ipc_perm 0777
slave {
pcm "hw:2,0"
period_time 0
period_size 96
buffer_size 1920
format S16_LE
periods 4
rate 9600
}
}
pcm.au600capture {
type rate
slave {
pcm "hw:2,0"
format S16_LE
rate 9600
}
}
pcm.duplex {
type asym
playback.pcm "au600playback"
capture.pcm "au600capture"
}
Tue Aug 15 01:44:42 CEST 2006
- removed some useless mixer controls (thought they were supported because I saw them in windows..)
- Added support for picking up the phone directly from the PC
- Tested DTMF dialing, works fine
- working on sysfs callback when a call comes in
$ amixer -c 2
Simple mixer control 'PC/PHONE',0
Capabilities: pswitch pswitch-joined
Playback channels: Mono
Mono: Playback [off]
Simple mixer control 'VOIPPSTN',0
Capabilities: pswitch pswitch-joined
Playback channels: Mono
Mono: Playback [on]
- PC/PHONE if switched on the PC picked up the line (this feature only works if VOIPPSTN is set to off (PSTN)
- VOIPPSTN if switched on the device mode is set to VOIP, otherwise to PSTN
Aug 13 2006
So Aug 13 22:04:10 CEST 2006
I figured out how playback and capturing audio is done "correctly". Support has been added to the current development driver.
The driver isn't completly done yet but I'd say it's 90% done.
Installation:
I developed that driver on a 2.6.16.16 kernel, so this one will probably be the best one.
hg is also called mercurial you can get a copy from: http://www.selenic.com/mercurial/wiki/index.cgi
Getting the sourcecode:
$ hg clone http://85.10.198.106/hg/~mrec/au600
$ cd au600
$ make
$ insmod au600.ko
This will create an alsa device and you can use that device as usbaudio device. Recording audio only works if playback is on.
ringing (as documented before):
$ echo 0 > /proc/au600/ring
$ cat /proc/au600/ring
0
$ echo 1 > /proc/au600/ring
$ cat /proc/au600/ring
1
switching from PSTN to VOIP:
$ aplay -l
$ alsamixer -c <devicenumber>
Comments
Do Aug 10 12:52:13 CEST 2006
playback in linux works fine now for 47 seconds afterwards it adds some buzz again, but I'm sure this will get fixed sooner or later. Used xmms for testing the audio device.
Di Aug 8 03:20:50 CEST 2006
ok fixed some parts of that driver.. the playback sounds clear now _but_ kinda choppy (as the underruns messages indicate).
Using log2bin.pl I verified that the outgoing data is PCM 9600Hz 16 Bit Mono (S16_LE). log2bin plays the transfered data clearly on my other soundcard.
SMlink sold their technology to conexant a while ago too
debian:/devel/kernel/au600# aplay -D hw:2,1 5_5_2006__07_00_59.wav
Playing WAVE '5_5_2006__07_00_59.wav' : Signed 16 bit Little Endian, Rate 9600 Hz, Mono
underrun!!! (at least 1,370 ms long)
underrun!!! (at least 0,456 ms long)
underrun!!! (at least 0,281 ms long)
underrun!!! (at least 1,644 ms long)
underrun!!! (at least 1,296 ms long)
underrun!!! (at least 0,275 ms long)
underrun!!! (at least 0,273 ms long)
Mo Mai 8 03:13:29 CEST 2006
figured out how playback is done, poor support is already implemented. To get it work correctly is just some extra homework now.
following line enables audio playback:
enable PCM playback:
000658: OUT: -00002 ms 006456 ms 40 17 c0 03 00 00 00 00 >>>
Sa May 6 18:09:06 CEST 2006
Todo:
- proper locking of critical codeparts
- implement the playback device (the outgoing format is also S16_LE/9600hz I think, it's uncompressed PCM)
The premature usb driver now supports
- recording wav files
- and switching from PSTN to VoIP mode
- ringing the phone
turn device on:?
usb_control_msg(h,0x40,0x08,0xbef8,0x0000,0x00,0x00,HZ);
enable status led:
usb_control_msg(h,0x40,0x0a,0x10c0,0x0000,0x00,0x00,HZ);
this sequence turns the data transfer on:
000047: OUT: 000002 ms 000373 ms 40 01 01 00 00 00 00 00 >>>
000074: OUT: -00001 ms 000501 ms 40 04 2f 00 00 00 00 00 >>>
this sequence turns the usb data transfer off:
000017: OUT: 000002 ms 000264 ms 40 04 00 00 00 00 00 00 >>>
make the phone ring:
010809: OUT: 000005 ms 015766 ms 40 0a c0 18 00 00 00 00 >>>
stop ringing:
012414: OUT: 000007 ms 017735 ms 40 0a ca 10 00 00 00 00 >>>
enable PCM capture:
000056: OUT: 000002 ms 000401 ms 40 19 00 a0 00 00 00 00 >>>
enable PCM playback:
000658: OUT: -00002 ms 006456 ms 40 17 c0 03 00 00 00 00 >>>
letting the phone ring
debian:/proc# echo 0 > /proc/au600/ring
debian:/proc# cat /proc/au600/ring
0
debian:/proc# echo 1 > /proc/au600/ring
debian:/proc# cat /proc/au600/ring
1
Fr May 5 16:24:07 CEST 2006
haven't worked on that project for a long time because I wrote a driver for an hybrid analogue TV/DVB-T usb device.. maybe I'll find some more time during the next few days to have a look at this project..
After updating the driver an app came up that supports recording. I compared the captured raw usb stream with the content of that recorded audio file that was stored on my disk -- everything's identical!
00000000 52 49 46 46 24 ce 01 00 57 41 56 45 66 6d 74 20 |RIFF$Î..WAVEfmt |
00000010 10 00 00 00 01 00 01 00 80 25 00 00 00 4b 00 00 |.........%...K..|
00000020 02 00 10 00 64 61 74 61 00 ce 01 00 fe 80 fe 28 |....data.Î..þ.þ(|
00000030 fe de fd a6 fd 8f fd a1 fd d1 fd 20 fe 6f fe b7 |þÞý¦ý.ý¡ýÑý þoþ·|
00000040 fe 19 ff 7f ff ea ff 3c 00 6e 00 9a 00 a3 00 88 |þ.ÿ.ÿêÿ<.n...£..|
The audiostream has following format:
AUDIO: 9600 Hz, 1 ch, s16le, 153.6 kbit/100.00% (ratio: 19200->19200)
Selected audio codec: [pcm] afm:pcm (Uncompressed PCM)
\ Di Jan 10 14:27:29 CET 2006
implemented isoc out transfer to the device - the interrupt and isoc endpoints are handled now, I also do receive raw data from the device now. Next step would be to analyze the received data.. well another day then..
isoc packet with length: 18
dumping packet: 0x66 0x36 0x74 0x36 0x66 0x36 0x6b 0x36 0x6e 0x36 0x64 0x36 0x65 0x36 0x63 0x36 0x60 0x36
isoc packet with length: 20
dumping packet: 0x66 0x36 0x74 0x36 0x66 0x36 0x6b 0x36 0x6e 0x36 0x64 0x36 0x65 0x36 0x63 0x36 0x60 0x36 0x6c 0x36
isoc packet with length: 18
dumping packet: 0x66 0x36 0x74 0x36 0x66 0x36 0x6b 0x36 0x6e 0x36 0x64 0x36 0x65 0x36 0x63 0x36 0x60 0x36
resubmitting isoc out!
phone is picked up!
phone is picked up!
phone is picked up!
phone is picked up!
phone is picked up!
phone is picked up!
phone is picked up!
phone is picked up!
phone is picked up!
phone is picked up!
phone is picked up!
phone is picked up!
incoming urb with length 128!
received: 40 packets
110001 .. 0x31
10110001 .. 0xb1
11000100 .. 0xc4
1010000 .. 0x50
10000 .. 0x10
024647: don't know how to handle ISOCH_TRANSFER
024648: OUT: <<< 91 00 c4 50
024650: OUT: c0 95 00 00 00 00 02 00 <<< c4 50
024652: OUT: <<< 91 00 c4 50
024654: OUT: c0 95 00 00 00 00 02 00 <<< c4 50
024655: OUT: <<< 91 00 c4 10
024658: don't know how to handle ISOCH_TRANSFER
024659: OUT: c0 95 00 00 00 00 02 00 <<< c4 10
024660: OUT: <<< 91 00 c4 10
024663: OUT: c0 95 00 00 00 00 02 00 <<< c4 10
looks like the same information is also accessable using the read control message "c0 95 00 00 00 00 02 00"
c4 50 and c4 10 is also returned within the IRQ function
IRQ responses:
this comes back if the phone is switched to VoIP, and the phone is off the station (active to speak)
data: 0x41 0x0 0xc4 0x10
data: 0xc1 0x0 0xc4 0x10
following data is received if the phone is switched to VoIP and not active
data: 0x41 0x0 0xc4 0x50
data: 0xc1 0x0 0xc4 0x50
next one comes in if the phone is switched to PSTN and not active (I have no PSTN connection here atm maybe there might show up something else if it's connected to the PSTN network I'll test it later)
data: 0xc1 0x0 0x0 0x40
data: 0x41 0x0 0x0 0x40
data: 0x41 0x0 0x0 0x40
enough for today...time for gettin a beer
Mo Jan 9 13:03:33 CET 2006
implemented isoc in transfer from the device, as well as interrupt transfers (code looks quite dirty now and the packets which are received are empty .. this is very likely because of a wrong device configuration which has to be set up using usb control messages .. so far so go od the device already plays ping pong with my notebook ..)
au600
Speed: 12Mb/s (full)
USB Version: 1.00
Device Class: 02(comm.)
Device Subclass: 00
Device Protocol: 00
Maximum Default Endpoint Size: 8
Number of Configurations: 1
Vendor Id: 0483
Product Id: 7554
Revision Number: 2.00
Config Number: 1
Number of Interfaces: 1
Attributes: a0
MaxPower Needed: 100mA
Interface Number: 0
Name: au600
Alternate Number: 0
Class: 02(comm.)
Sub Class: 80
Protocol: 0
Number of Endpoints: 1
Endpoint Address: 81
Direction: in
Attribute: 19
Type: Int.
Max Packet Size: 4
Interval: 1ms
Interface Number: 0
Name: au600
Alternate Number: 1
Class: 02(comm.)
Sub Class: 80
Protocol: 0
Number of Endpoints: 3
Endpoint Address: 81
Direction: in
Attribute: 19
Type: Int.
Max Packet Size: 4
Interval: 1ms
Endpoint Address: 02
Direction: out
Attribute: 5
Type: Isoc
Max Packet Size: 128
Interval: 1ms
Endpoint Address: 83
Direction: in
Attribute: 5
Type: Isoc
Max Packet Size: 128
Interval: 1ms
Interface Number: 0
Name: au600
Alternate Number: 2
Class: 02(comm.)
Sub Class: 80
Protocol: 0
Number of Endpoints: 3
Endpoint Address: 81
Direction: in
Attribute: 19
Type: Int.
Max Packet Size: 4
Interval: 1ms
Endpoint Address: 04
Direction: out
Attribute: 5
Type: Isoc
Max Packet Size: 128
Interval: 1ms
Endpoint Address: 85
Direction: in
Attribute: 5
Type: Isoc
Max Packet Size: 128
Interval: 1ms
Interface Number: 0
Name: au600
Alternate Number: 3
Class: 02(comm.)
Sub Class: 80
Protocol: 0
Number of Endpoints: 5
Endpoint Address: 81
Direction: in
Attribute: 19
Type: Int.
Max Packet Size: 4
Interval: 1ms
Endpoint Address: 02
Direction: out
Attribute: 5
Type: Isoc
Max Packet Size: 128
Interval: 1ms
Endpoint Address: 83
Direction: in
Attribute: 5
Type: Isoc
Max Packet Size: 128
Interval: 1ms
Endpoint Address: 04
Direction: out
Attribute: 5
Type: Isoc
Max Packet Size: 128
Interval: 1ms
Endpoint Address: 85
Direction: in
Attribute: 5
Type: Isoc
Max Packet Size: 128
Interval: 1ms
most important is to know what alternate number was used within the windows driver:
$ grep -i Altern usbsnoop.log
Interface[0]: AlternateSetting = 1
Interface[0]: AlternateSetting = 1
so we fixate on Alternate number 1
What endpoint pins are used? ..
grep -i endpoint * | sort | uniq
Interface[0]: Pipes[0] : EndpointAddress = 0x00000081
Interface[0]: Pipes[1] : EndpointAddress = 0x00000002
Interface[0]: Pipes[2] : EndpointAddress = 0x00000083
PipeHandle = 80e02e80 [endpoint 0x00000081]
PipeHandle = 80e02e80 [endpoint 0x00000081]
PipeHandle = 80e02e9c [endpoint 0x00000002]
PipeHandle = 80e02e9c [endpoint 0x00000002]
PipeHandle = 80e02eb8 [endpoint 0x00000083]
PipeHandle = 80e02eb8 [endpoint 0x00000083]
So 81, 02 and 83 are used we also see them in configuration 0 alternate
1 good :)
81 is an interrupt endpoint
02 an isochronous out data endpoint
83 an isochronous in data endpoint
Sa Jan 7 03:25:22 CET 2006
implemented a mixer control for switching from PSTN to VoIP
debian:/devel/usb/usbfs/aufgabe5# amixer -c 2
Simple mixer control 'Master',0
Capabilities: volume volume-joined
Playback channels: Mono
Limits: 0 - 256
Mono: 0 [0%]
Simple mixer control 'Midi',0
Capabilities: volume volume-joined
Playback channels: Mono
Limits: 0 - 256
Mono: 0 [0%]
Simple mixer control 'VoIP Input Select',0
Capabilities: pswitch pswitch-joined
Playback channels: Mono
Mono: Playback [off]
Index 0x0
IndexValues:
1000011000000 .. 0x10c0 VoIP
0000011000000 .. 0x00c0 PSTN
the first bit is for switching to VoIP if it's 1 the device is set to VoIP
0000010000000 .. 0x80 this bit toggles the Link led
0000000000000 .. 0x00
Do Jan 5 19:46:39 CET 2006
Implemented the Alsa frontend:
$ cat /proc/asound/cards
0 [I82801DBICH4 ]: ICH4 - Intel 82801DB-ICH4
Intel 82801DB-ICH4 with ALC202 at 0xe0100c00, irq 10
1 [Modem ]: ICH-MODEM - Intel 82801DB-ICH4 Modem
Intel 82801DB-ICH4 Modem at 0x2400, irq 10
2 [AU-600 ]: AU-600 VoIP - AU-600
AU-600 VoIP USB Adapter
$ amixer -c 2
Simple mixer control 'Midi',0
Capabilities: volume volume-joined
Playback channels: Mono
Limits: 0 - 255
Mono: 0 [0%]
Simple mixer control 'Volume',0
Capabilities: volume volume-joined
Playback channels: Mono
Limits: 0 - 255
Mono: 0 [0%]
Retrieved from "http://alsa.opensrc.org/Au600"