I have a embedded platform with two audiocodec. One is a tlv320aic3x (I2S) codec and the other is a USB Codec. The scenario is that a rtp stream is forwarded with a PjProject conferencer to the two codecs. When the call is established there is a underrun for both codecs. The pjmedia part detects the underrun and prepares and starts the codecs new. There is no Problem with the USB codec but the I2S codec has sometimes no playback after the new start. The playback callback for the codec blocks in the function snd_pcm_wait_nocheck in the poll call. I think the problem is that he waits until the file descriptor is ready to be written but the driver is not read out the data. Does anybody knows the problem or can give me a hint where i can find the problem?!
Related
I have an FPGA board with unix-based firmware. I need write out the program to run on this firmware that will send commands to some devices via I2C bus and will receive responses. I use for this special character file in Unix that i map in my program and write to it special commands & read from it responses. Each memory area in this mapped memory corresponds specific register of the FPGA which specified in Unix-based firmware (as i understand).
So, the question is the next one. As i understand, when i write some command to that mapped memory region of the special character file the kernel calls certain driver to handle bytes that I've written and send them through I2C bus (for example). Am I right? If so, is there some guarantee that the response from that device will be buffered and I will be able to read it from the mapped region in any time? Or does it depend on implementation specific driver?
I'm sorry if question is not clear some way, I am a newbie in this stuff.
I'm receiving a RTP/UDP from a hardware encoder, I have tried ffmpeg, so it takes this input and outputs the stream as FLV (it's being sent to NGINX, nginx-rtmp-module). However I'm not able to play the stream smoothly once it's received by nginx, some frames are broken or lost, etc.
I think that my CPU is too slow for this format change (FLV) and/or ffmpeg is missing a lot of RTP packets. Any ideas?
Using a FPGA board, how to initialize the audio codec chip, WM8731, to 16-bit mode at 8 kHz sampling rate, and the input coming from the LINE IN terminal? I have no idea how to start working on the quuestion. Can any body please help me out
WM8731 need to be programmed with initialization parameters for it to work.
Ask for the codec evaluation board from the Wolfson, the evaluation board comes with the source code for configuring the codecs.
This codec can be programed with SPI interface and 2 wire MPU interface. You can also learn more about this at http://www.cs.columbia.edu/~sedwards/classes/2008/4840/
http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/sound/soc/codecs/wm8731.c
I have a GSM ModeM connected to a serial port, and I use it so send SMS upon certain events.
Since it is not Plug-and-Play, I am confused as to how I'll detect its connection status. Win APIs like GetCommState will obviously not work.
I could periodically send packets of data and check whether the data is being consumed or not, but I'm wary about the risks of polling over performance and clogging up the buffers which might be in use.
So, is there any other method, or some interrupt based thing, which I could use to check whether is still connected, via a serial port, to my system?
I'd be grateful for any help on this.
Thanks.
From Windows 7 onwards, use Windows Mobile Broadband API to get information about a GSM modem.
Serial ports are very primitive communication devices, they date from the very early days of computing. It is what you plugged your ASR-33 teletype into to start banging in your Fortran program. The only reason they are still around is because they are simple, hardware vendors like them because they don't have to spend money developing and supporting a custom api to use their device.
Still, even back in the sixties did a computer have a need to find out if a teletype was attached. Which is done through the hardware handshake signals. The DSR signal, Data Set Ready, is turned on by the device when it is powered up. If you use the .NET SerialPort class then you can check that signal with the SerialPort.DsrHolding property. If you use the winapi then use GetCommModemStatus(), MS_DSR_ON flag.
That still only tells you that some device is attached. If you want to find out that it is the modem that you wrote your program for then you can interrogate it with AT commands, a protocol that's specific to modems. No vendor implements this exactly the same way but you can usually count on an identification from the modem with the ATI command. Check the programming manual for the modem for details.
I am working on a smartcard reader project here i will have to read/write data from the smartcard reader.
Also i will have to read/write data from PC application.
There are two serial port on my microcontroller one connected to smartcard reader other to PC.
Smartcard reader <------> Microcontroller <-----> PC
I have ported linux & using /ttys0 & /ttys1 driver for this.
1> My question is if application have to find that some data is available to be read from the port than will i have to always check it with read() system call ?
2> Does ttys0 driver have internal buffer to store received data ? Or data is lost if application do not read data immediately ?
3> Here using seprate threads for rx/tx from each port, is it right approach ?
Please guide me i am new to Embedded linux.
//John
Yes, there's a fair amount of buffering on linux tty's.
You have a few choices for how to interact with them.
you can make them non-blocking, and frequently poll to see if you can read data from them (but this may result in uselessly spinning CPU cycles, slowing other tasks)
you can use select() to yield to the scheduler until one of your devices has data for you to act on
you can use blocking I/O, however since you have multiple ports that may also require multiple threads
TTY programming is similar to socket programming in Linux. So basically you can set the socket to be a asynchronous and receive a signal once data is available. Regarding buffering, yes it's buffered using two flipping buffers. You can check chapter 18 in Linux device drivers 3rd edition regarding TTY implementation in the kernel.