From: Bob v. L. <bob...@gm...> - 2009-10-28 23:41:29
Attachments:
audiosend.diff
|
Hi, The attached patch add send support to hw_audio. An 18 kHz carrier is generated in antiphase on the left and right outputs, when rectified this makes a 36 kHz carrier wave. The simplest way of rectifying would be to connect two IR leds antiparallel to the left and right outputs (hence the antiphase, gives more voltage, gnd is not used). This works for me with a philips RC19002 at a distance of about 4 meters when directly aiming. Regards, Bob. |
From: <li...@ba...> - 2009-10-29 07:23:14
|
Hi! Bob van Loosen "bob...@gm..." wrote: > The attached patch add send support to hw_audio. > > An 18 kHz carrier is generated in antiphase on the left and right > outputs, when rectified this makes a 36 kHz carrier wave. > The simplest way of rectifying would be to connect two IR leds > antiparallel to the left and right outputs (hence the antiphase, gives > more voltage, gnd is not used). Can you put together some website/documentation to be included with LIRC with some schematics? Otherwise hardly anyone will be able to take advantage of your code. Christoph |
From: Bob v. L. <bob...@gm...> - 2009-10-29 20:19:35
Attachments:
audiosend2.diff
|
Christoph Bartelmus wrote: > Hi! > > Bob van Loosen "bob...@gm..." wrote: > >> The attached patch add send support to hw_audio. >> >> An 18 kHz carrier is generated in antiphase on the left and right >> outputs, when rectified this makes a 36 kHz carrier wave. >> The simplest way of rectifying would be to connect two IR leds >> antiparallel to the left and right outputs (hence the antiphase, gives >> more voltage, gnd is not used). >> > > Can you put together some website/documentation to be included with LIRC > with some schematics? Otherwise hardly anyone will be able to take > advantage of your code. > > Christoph > Will do. I have attached my latest patch which addresses two issues: - Input needs to be ignored when transmitting, with this patch it ignores one second of input since the latest transmit. This could be improved by using the input and output latency, but it seems to be a bit complicated. - The full buffer needs to be played out before shutting down portaudio. Although portaudio should guarantee this it doesn't seem to work, a simple sleep the length of the output latency fixed that. Bob. |
From: <li...@ba...> - 2009-10-29 20:44:42
|
Hi! Bob van Loosen "bob...@gm..." wrote: [...] > I have attached my latest patch which addresses two issues: Please use C-style comments and put variable declarations at the beginning of blocks. Older compilers won't compile this code. Christoph |
From: Bob v. L. <bob...@gm...> - 2009-10-31 16:53:10
|
<html> <head> </head> <body> Using the audio driver for transmitting.<br> <br> <br> Pros:<br> <br> Very simple circuit.<br> No need for a kernel module.<br> <br> Cons:<br> <br> Doesn't transmit very far without an amplifier (about 3 meters when directly aiming).<br> A reasonably good soundcard is required (cheap cards might not provide enough voltage, or might not be able to output a correct 18 kHz sine).<br> <br> <br> How it works:<br> <br> The audio driver can send IR signals using a (reasonably good) soundcard and a very simple circuit.<br> It does this by outputting a 18 kHz sine, which after rectification becomes a 36 kHz carrier wave.<br> The wave is inverted on the right channel, so the left and right channels can be used to double the voltage.<br> <br> <img src="wave.png"> <br> The top wave is how the wave looks when it comes out the soundcard,<br> the bottom wave is how it looks after rectification, as you can see the frequency is doubled.<br> <br> The rectification is done using the following circuit:<br> <br> <img src="transmitter.png"><br> <br> LED1 and LED2 are 950nm infrared leds, R1 is a 0.25 watt resistor.<br> <br> Because leds are diodes, they only conduct one way.<br> Since the soundcard outputs a wave that goes both positive and negative, two leds are placed antiparallel,<br> that way infrared is emitted on both the positive and negative cycles.<br> <br> R1 is used to limit the current, this presents a load to the soundcard that is roughly the same as a pair of 32 ohms headphones.<br> To make the transmission more powerful, you can try lowering the value of R1 (or just short it out),<br> but this might damage your soundcard, the leds, or both. So try at your own risk!<br> <br> Another way to make the transmission more powerful is to use a small speaker amplifier (5 watts or less),<br> in this case a 5 watt resistor should be used for safety. The volume should be adjusted so that the amplifier outputs its full voltage without clipping.<br> <br> <br> Setting up:<br> <br> Compile lirc with the audio driver (not the IR diode or alsa ones) and install it as usual.<br> Connect the circuit to the soundcard and set the volume to the maximum level.<br> Use irsend to test if it works.<br> <br> Known issues:<br> <br> The audio driver uses portaudio to interface with the soundcard, there seems to be a bug in some later versions<br> that makes portaudio hang completely, lircd becomes unresponsive and you have to kill it with killall -9 lircd.<br> To get around this use the portaudio stable release from December 7, 2007.<br> </body> </html> |
From: <li...@ba...> - 2009-11-07 20:11:10
|
Hi! Bob van Loosen "bob...@gm..." wrote: > Latest patch and documentation. What's the reason for changing SAMPLE_RATE to 48000? Unless there's a very good reason I'd like to keep the current value to avoid problems with soundcards that only support 44100. Christoph |
From: Ryan V. <sim...@ya...> - 2009-11-07 20:16:56
|
On Saturday 07 November 2009 15:08:00 Christoph Bartelmus wrote: > Hi! > > Bob van Loosen "bob...@gm..." wrote: > > Latest patch and documentation. > > What's the reason for changing SAMPLE_RATE to 48000? > Unless there's a very good reason I'd like to keep the current value to > avoid problems with soundcards that only support 44100. > > Christoph While i don't know his exact motivations, it should allow for a better approximation of the 18000 wave which should make it work more reliably. |
From: <li...@ba...> - 2009-11-07 20:47:38
|
Hi! Ryan Voots "sim...@ya..." wrote: > On Saturday 07 November 2009 15:08:00 Christoph Bartelmus wrote: >> Bob van Loosen "bob...@gm..." wrote: >>> Latest patch and documentation. >> >> What's the reason for changing SAMPLE_RATE to 48000? >> Unless there's a very good reason I'd like to keep the current value to >> avoid problems with soundcards that only support 44100. >> > While i don't know his exact motivations, it should allow for a better > approximation of the 18000 wave which should make it work more reliably. Hm, I'm not convinced that it gives a substantial improvement. But it brings me to the next point: the carrier should not be fixed. It should be derived from the frequency set in the remote configuration. Anything above the SAMPLE_RATE probably should just be limited to SAMPLE_RATE. And maybe carrierPos should always start with 90°. Otherwise you'll get no output at all if sample_rate == 2 * carrier. The longer I think about this the more surprised I am that this really works. Christoph |
From: Bob v. L. <bob...@gm...> - 2009-11-07 20:49:28
|
Christoph Bartelmus wrote: > Hi! > > Bob van Loosen "bob...@gm..." wrote: > >> Latest patch and documentation. >> > > What's the reason for changing SAMPLE_RATE to 48000? > Unless there's a very good reason I'd like to keep the current value to > avoid problems with soundcards that only support 44100. > > Christoph A higher samplerate increases the rolloff frequency of the soundcard's internal lowpass, considering the high carrier frequency and the square carrier modulation you need all the bandwidth you can get to ensure reliable transmission. I don't think it's much of an issue considering that almost all soundcards do 48 khz for the past 8 years or so, even the really cheap ones. Bob. |
From: <li...@ba...> - 2009-11-07 21:05:19
|
Hi! Bob van Loosen "bob...@gm..." wrote: [...] >> What's the reason for changing SAMPLE_RATE to 48000? >> Unless there's a very good reason I'd like to keep the current value to >> avoid problems with soundcards that only support 44100. >> > A higher samplerate increases the rolloff frequency of the soundcard's > internal lowpass, considering the high carrier frequency and the square > carrier modulation you need all the bandwidth you can get to ensure > reliable transmission. > I don't think it's much of an issue considering that almost all > soundcards do 48 khz for the past 8 years or so, even the really cheap ones. Ok, can we make this configurable, the same way it is done for the audio_alsa driver? Then I wouldn't have any problem setting the default to 48kHz. Christoph |
From: Bob v. L. <bob...@gm...> - 2009-11-07 21:35:36
|
Christoph Bartelmus wrote: > Hi! > > Bob van Loosen "bob...@gm..." wrote: > [...] > >>> What's the reason for changing SAMPLE_RATE to 48000? >>> Unless there's a very good reason I'd like to keep the current value to >>> avoid problems with soundcards that only support 44100. >>> >>> >> A higher samplerate increases the rolloff frequency of the soundcard's >> internal lowpass, considering the high carrier frequency and the square >> carrier modulation you need all the bandwidth you can get to ensure >> reliable transmission. >> I don't think it's much of an issue considering that almost all >> soundcards do 48 khz for the past 8 years or so, even the really cheap ones. >> > > Ok, can we make this configurable, the same way it is done for the > audio_alsa driver? Then I wouldn't have any problem setting the default to > 48kHz. Sure, all that's needed is to replace the SAMPLE_RATE constant with a variable that's set somewhere. Bob. |
From: Bob v. L. <bob...@gm...> - 2009-11-09 17:05:22
Attachments:
audiosend4.diff
|
Christoph Bartelmus wrote: > Hi! > > Bob van Loosen "bob...@gm..." wrote: > [...] > >>> What's the reason for changing SAMPLE_RATE to 48000? >>> Unless there's a very good reason I'd like to keep the current value to >>> avoid problems with soundcards that only support 44100. >>> >>> >> A higher samplerate increases the rolloff frequency of the soundcard's >> internal lowpass, considering the high carrier frequency and the square >> carrier modulation you need all the bandwidth you can get to ensure >> reliable transmission. >> I don't think it's much of an issue considering that almost all >> soundcards do 48 khz for the past 8 years or so, even the really cheap ones. >> > > Ok, can we make this configurable, the same way it is done for the > audio_alsa driver? Then I wouldn't have any problem setting the default to > 48kHz. > > Christoph Attached patch should do it. Bob. |
From: <li...@ba...> - 2009-11-09 20:39:37
|
Hi! Bob van Loosen "bob...@gm..." wrote: [...] >> Ok, can we make this configurable, the same way it is done for the >> audio_alsa driver? Then I wouldn't have any problem setting the default to >> 48kHz. >> > Attached patch should do it. Almost there. I saw that you've added carrierFreq to the struct but are not using it yet. In audio_send you can use something like: data.carrierFreq = remote->freq==0 ? DEFAULT_FREQ:remote->freq; And then of course make use of it in recordCallback. Christoph |
From: Bob v. L. <bob...@gm...> - 2009-11-10 17:14:52
|
Christoph Bartelmus wrote: > Hi! > > Bob van Loosen "bob...@gm..." wrote: > [...] > >>> Ok, can we make this configurable, the same way it is done for the >>> audio_alsa driver? Then I wouldn't have any problem setting the default to >>> 48kHz. >>> >>> >> Attached patch should do it. >> > > Almost there. > I saw that you've added carrierFreq to the struct but are not using it > yet. > In audio_send you can use something like: > data.carrierFreq = remote->freq==0 ? DEFAULT_FREQ:remote->freq; > And then of course make use of it in recordCallback. > > Christoph > Should be done with the pipe instead, otherwise it's not threadsafe. Bob. |
From: <li...@ba...> - 2009-11-10 17:26:21
|
Hi! Bob van Loosen "bob...@gm..." wrote: [...] >> Almost there. >> I saw that you've added carrierFreq to the struct but are not using it >> yet. >> In audio_send you can use something like: >> data.carrierFreq = remote->freq==0 ? DEFAULT_FREQ:remote->freq; >> And then of course make use of it in recordCallback. >> > Should be done with the pipe instead, otherwise it's not threadsafe. Hm, you've serialized access with completedPipe already, or do I miss something? Christoph |
From: Bob v. L. <bob...@gm...> - 2009-11-10 21:30:14
|
Christoph Bartelmus wrote: > Hi! > > Bob van Loosen "bob...@gm..." wrote: > [...] > >> Should be done with the pipe instead, otherwise it's not threadsafe. >> > > Hm, you've serialized access with completedPipe already, or do I miss > something? > > Christoph That part is ok, but I'm not sure you can guarantee synchronization between the data written/read from sendPipe and the assignment of the carrier frequency. Bob. |
From: <li...@ba...> - 2009-11-10 21:51:31
|
Hi! Bob van Loosen "bob...@gm..." wrote: [...] >>> Should be done with the pipe instead, otherwise it's not threadsafe. >>> >> >> Hm, you've serialized access with completedPipe already, or do I miss >> something? >> >> Christoph > That part is ok, but I'm not sure you can guarantee synchronization > between the data written/read from sendPipe and the assignment of the > carrier frequency. Wait, this whole thing won't work anyway. fork() creates a new process with its own address space. You can change any variable in the parent process as you like, it won't affect the child. Shared memory seems like overkill, so maybe your first idea with using sendPipe to pass the carrier frequency to the child is the best option. Christoph |
From: Bob v. L. <bob...@gm...> - 2009-11-14 16:24:04
Attachments:
audiosend5.diff
|
Christoph Bartelmus wrote: > Hi! > > Bob van Loosen "bob...@gm..." wrote: > [...] > >> That part is ok, but I'm not sure you can guarantee synchronization >> between the data written/read from sendPipe and the assignment of the >> carrier frequency. >> > > Wait, this whole thing won't work anyway. fork() creates a new process > with its own address space. You can change any variable in the parent > process as you like, it won't affect the child. > Shared memory seems like overkill, so maybe your first idea with using > sendPipe to pass the carrier frequency to the child is the best option. Latest patch assigns carrier frequency, I also added a usleep to give portaudio some time to set up properly, otherwise the first transmission might fail. Bob. |
From: Bob v. L. <bob...@gm...> - 2009-11-14 16:43:11
|
<html> <head> </head> <body> <b>Using the audio driver for transmitting.</b><br> <br> Pros:<br> <br> Very simple circuit.<br> No need for a kernel module.<br> <br> Cons:<br> <br> Doesn't transmit very far without an amplifier (about 3 meters when directly aiming).<br> A reasonably good soundcard is required (cheap cards might not provide enough voltage, or might not be able to output a correct 18 kHz sine).<br> <br> It takes some time to set up (50 ms or so) so when no clients are connected to lircd the first transmission will have some higher latency.<br> A workaround for this is to keep irw running with a bash script like this:<br> <br> <code> #!/bin/bash<br> while [ true ]; do<br> irw || true<br> sleep 1<br> done<br> </code> <br> <b>How it works:</b><br> <br> The audio driver can send IR signals using a (reasonably good) soundcard and a very simple circuit.<br> It does this by outputting a 18 kHz sine, which after rectification becomes a 36 kHz carrier wave.<br> The wave is inverted on the right channel, so the left and right channels can be used to double the voltage.<br> <br> <img src="wave.png"> <br> The top wave is how the wave looks when it comes out the soundcard,<br> the bottom wave is how it looks after rectification, as you can see the frequency is doubled.<br> <br> The rectification is done using the following circuit:<br> <br> <img src="transmitter.png"><br> <br> LED1 and LED2 are 950nm infrared leds, R1 is a 0.25 watt resistor.<br> <br> Because leds are diodes, they only conduct one way.<br> Since the soundcard outputs a wave that goes both positive and negative, two leds are placed antiparallel,<br> that way infrared is emitted on both the positive and negative cycles.<br> <br> R1 is used to limit the current, this presents a load to the soundcard that is roughly the same as a pair of 32 ohms headphones.<br> To make the transmission more powerful, you can try lowering the value of R1 (or just short it out),<br> but this might damage your soundcard, the leds, or both. So try at your own risk!<br> <br> Another way to make the transmission more powerful is to use a small speaker amplifier (5 watts or less),<br> in this case a 5 watt resistor should be used for safety. The volume should be adjusted so that the amplifier outputs its full voltage without clipping.<br> <br> <b>Setting up:</b><br> <br> Compile lirc with the audio driver (not the IR diode or alsa ones) and install it as usual.<br> Connect the circuit to the soundcard and set the volume to the maximum level.<br> Start lircd, the -d flag can be used to select the audio device and/or samplerate, the syntax is api:device[@samplerate] or @samplerate.<br> Examples:<br> <br> <code> lircd -d ALSA:default<br> lircd -d ALSA:default@48000<br> lircd -d @48000.<br> </code> <br> Use irsend to test if it works.<br> <br> <b>Known issues:</b><br> <br> The audio driver uses portaudio to interface with the soundcard, there seems to be a bug in some later versions<br> that makes portaudio hang completely, lircd becomes unresponsive and you have to kill it with killall -9 lircd.<br> To get around this use the portaudio stable release from December 7, 2007.<br> </body> </html> |
From: <li...@ba...> - 2009-11-15 13:53:13
|
Hi! Bob van Loosen "bob...@gm..." wrote: [...] > Latest patch assigns carrier frequency, I also added a usleep to give > portaudio some time to set up properly, otherwise the first transmission > might fail. Is in CVS now. I've done some slight modifications (e.g. default carrier is 38kHz in LIRC). Please check if everything is still working as expected. Christoph |
From: Bob v. L. <bob...@gm...> - 2009-11-19 17:58:35
|
Christoph Bartelmus wrote: > Hi! > > Bob van Loosen "bob...@gm..." wrote: > [...] > >> Latest patch assigns carrier frequency, I also added a usleep to give >> portaudio some time to set up properly, otherwise the first transmission >> might fail. >> > > Is in CVS now. I've done some slight modifications (e.g. default carrier > is 38kHz in LIRC). > Please check if everything is still working as expected. > > Christoph Everything is working as intended, thanks for committing. Bob. |