Fun with HVR-1600 ALSA Audio

I spent some time this weekend dealing with various users of the “DVICO Dual Digital 4” who were seeing that zl10353 regression I have fixed on four other boards so far. I can say some choice words about the person who submitted the patch that caused the breakage, or the person who blindly accepted it upstream without considering the implications for all the other products, but there isn’t much value in pointing fingers at this point. I just don’t have the time/energy to go through and fix *all* the effected products, so I have to deal with them as people report the problem.

The big project I’ve been working on for the last few days has been the HVR-1600 ALSA audio support. This will result in an ALSA device being present which can be used in conjunction with capturing raw video. Andy Walls was kind enough to point me to some skeleton code he wrote a few months ago and never had the time to get working. I cleaned it up a bit and now need to get the DMA code working properly. Because I don’t want to break compatibility with the existing PCM device, I need to be careful in how the stream gets multiplexed to both the ALSA subsystem and the original device node. This creates some interesting implications on things like mmap and the buffer management for the firmware queues.

If all goes well, I should basically have it “working” this week and just need to test and nail down any edge cases.

3 thoughts on “Fun with HVR-1600 ALSA Audio

  1. Devin, thanks for the recent performance updates (and thanks to ONELAN Limited!!) Can you tell me what the use case might be for the ALSA Audio changes? It sounds interesting, but I don’t know what I might use it for.

    Thanks!

    Brandon

    • Well, I cannot speak to ONELAN’s intended use case, but one use case worth considering is if you want to watch realtime television without the CPU cost of decoding the MPEG video. The MPEG encoder is great, but if you are just watching LiveTV with no intention of saving the content to disk, then your system is incurring the extra CPU cost associated with decoding the MPEG stream. Also, if you want to use the product with something like a video game console, you would want to avoid the latency that is introduced by the MPEG encoding in the card and the subsequent decoding on your PC.

      Don’t misunderstand me though – the MPEG encoder is *extremely* useful in many use cases. However, there are use cases where being able to watch the raw video/audio stream is useful to.

      Devin

  2. ALSA nodes could also be used for listening to FM radio (HVR-1600 MCE) or just
    monitoring TV station audio. You could do either of those with the /dev/video24
    node too, but there are not many apps that know how to deal with that /dev/video24
    node and V4L2 controls for volume, mute, etc. (The StudioToGo LiveCD has some
    really neat Linux audio apps all in one place and almost all of them need ALSA.)

    And yes live video game play has come up in the past on the ivtv lists.

    Live viewing and recording of a camera also come to mind. With an HVR -1600 you can
    be recording an MPEG stream to disk while you use the YUV and PCM stream for
    real time monitoring of the frames being captured by a camera and audio from the mic..

    Regards,
    Andy

Leave a Reply