1. 项目概述与核心价值最近在折腾一块全志T113-i的开发板主要想用它来跑一些音视频相关的应用。说实话嵌入式音视频开发的门槛不低从硬件接口、驱动配置到上层应用调试每一步都可能遇到意想不到的坑。网上能找到的资料要么太零散要么就是官方文档那种“只告诉你做什么不告诉你为什么”的风格真到动手的时候还是两眼一抹黑。所以我花了些时间把T113-i这块板子上音视频功能的完整测试流程从底层配置到上层命令都系统地走了一遍并且把过程中的关键原理、操作细节和踩过的坑都记录了下来。这篇文章就是这份实战笔记的整理希望能帮到同样在T113-i平台上进行音视频开发的同行们让大家能快速上手把宝贵的精力用在业务逻辑上而不是在基础功能验证上反复折腾。全志T113-i这颗SoC集成了双核Cortex-A7 CPU和一个HiFi4 DSP在多媒体处理上有着不错的潜力。它支持多种视频编解码格式和音频接口但潜力要转化为实际能力离不开正确的配置和调试。无论是想验证板子的音视频输出是否正常还是为后续的摄像头采集、流媒体播放、语音对讲等应用打基础一套清晰、可复现的测试方法都是必不可少的。接下来我会从最基础的视频播放测试开始逐步深入到音频的录制、播放、混音配置和音量控制不仅告诉你命令怎么敲更会解释每个参数背后的含义以及在不同场景下该如何调整。如果你是嵌入式Linux的初学者可以跟着步骤一步步操作如果你是有经验的开发者也可以直接跳到感兴趣的章节参考其中的配置思路和问题排查方法。2. 测试环境搭建与前期准备2.1 硬件连接与确认在开始任何软件操作之前确保硬件连接正确是第一步这能避免很多“灵异”问题。我使用的是眺望电子的EVM-T113-i评估板。你需要准备以下东西开发板EVM-T113-i主板。电源使用配套的12V/2A电源适配器稳定供电是基础。显示设备板子带有HDMI接口准备一根HDMI线连接至显示器或电视。有些板子也可能支持RGB/LVDS屏需要根据你的具体板型连接对应的屏幕。音频设备扬声器板载有扬声器输出接口通常标记为SPK和SPK-可以连接一个小喇叭。更常见的是通过HDMI输出音频到显示器。耳机/麦克风准备一个3.5mm接口的耳机带麦克风功能的最佳插入板子上标记为“AUDIOOUT”的3.5mm复合音频接口。这个接口既支持音频输出耳机听也支持音频输入麦克风录。存储介质准备一个TF卡用于存放测试用的视频和音频文件。将板子启动并挂载TF卡后文件通常位于/mnt/或/media/目录下。我建议在TF卡根目录创建一个talowe_test文件夹把所有测试文件放进去方便管理。串口调试工具这是嵌入式开发的“生命线”。通过USB转TTL串口线连接板子的调试串口通常是UART0使用MobaXterm、SecureCRT或Minicom等工具设置波特率为115200进行命令行操作和日志查看。注意首次上电或更换屏幕后如果无显示先检查电源指示灯是否正常然后通过串口查看内核启动日志确认DRMDirect Rendering Manager驱动是否成功加载并识别了显示设备。有时需要根据屏幕型号修改设备树Device Tree中的显示参数。2.2 软件系统与工具链测试基于板子预装的Linux系统通常是基于Buildroot或Yocto定制的。你需要确认系统中已包含以下关键工具和组件如果缺少可能需要重新构建根文件系统镜像。GStreamer这是进行视频播放测试的核心多媒体框架。我们需要用到其命令行工具gst-launch-1.0。通过串口执行gst-launch-1.0 --version来确认其是否存在及版本。T113-i平台通常会使用GStreamer的sunxi插件集其中包含了针对全志芯片优化的编解码器。ALSAAdvanced Linux Sound Architecture工具集这是Linux音频子系统的核心。我们需要用到tinymix: 一个轻量级的混音器控制工具用于配置音频通路如选择哪个麦克风输入、调整增益。arecord/aplay: 分别用于录制和播放PCM脉冲编码调制格式的原始音频文件。alsamixer: 一个基于ncurses的图形化混音器界面方便交互式调整音量。amixer:alsamixer的命令行版本适合用于脚本中的音量控制。 可以通过tinymix -h和arecord --version来检查这些工具是否可用。测试文件视频文件准备一个常见的视频文件如jj.mp4H.264编码AAC音频。将其拷贝到TF卡的talowe_test目录下。如果系统自带测试文件路径可能已在/talowe_test/下。音频脚本系统可能自带一个测试脚本如/talowe_test/test_audio.sh它会播放一段预置的测试音效用于快速验证音频输出通路是否畅通。确保你通过串口登录到开发板的Linux系统并拥有root权限通常提示符为#因为很多音频设备的操作需要高权限。3. 视频播放测试全流程解析视频播放是验证显示系统和解码能力最直观的方式。在嵌入式Linux中我们通常使用GStreamer这个强大的管道式多媒体框架。下面这个命令看似简单但每一个环节都值得深究。3.1 核心命令深度拆解输入的命令是gst-launch-1.0 filesrc location/talowe_test/jj.mp4 ! decodebin ! videoconvert ! autovideosink这条命令构建了一个GStreamer处理管道Pipeline。我们把它拆开来看filesrc location/talowe_test/jj.mp4作用源元素Source Element。它从指定位置/talowe_test/jj.mp4读取原始数据流。为什么用它这是最直接的本地文件读取方式。除了filesrc还可以用httpsrc处理网络流v4l2src处理摄像头采集。这里我们测试本地文件所以用filesrc。注意事项确保路径正确且文件有读取权限。如果文件不存在或路径错误GStreamer会报错“找不到文件”。路径中的talowe_test是我举例的目录请替换为你实际的路径。! decodebin作用解码器容器Decoder Bin。它是一个智能元素会自动检测输入流的容器格式如MP4和编码格式如H.264视频AAC音频然后动态创建并连接对应的解码器插件如avdec_h264用于视频faad用于音频。为什么用它省去了我们手动指定具体解码器的麻烦尤其当不确定文件编码格式时非常有用。它会输出原始的、解码后的视频帧和音频样本。关键点decodebin是异步的。当它连接到下游元素如videoconvert时会尝试进行能力协商Caps Negotiation。如果系统里没有对应的解码器插件管道会失败。对于T113-i确保已安装gstreamer1.0-plugins-good,-bad,-ugly包含更多编解码器以及全志提供的gstreamer1.0-sunxi插件。! videoconvert作用视频格式转换器。它将解码器输出的原始视频帧可能是YUV420, NV12, RGB等格式转换为下游sink元素这里是autovideosink所支持的格式。为什么需要它不同的硬件加速后端或显示接口对输入图像格式有严格要求。例如某些直接渲染的sink可能只接受特定的RGB或YUV排列。videoconvert在软件层面进行格式转换保证了管道的通用性。性能考量这是一个纯软件转换会消耗一定的CPU资源。在追求极致性能的场景下如果确定解码器输出格式与sink需求完全匹配可以尝试省略它。但作为通用测试加上它能避免很多因格式不匹配导致的绿屏或花屏问题。! autovideosink作用自动视频输出器Sink Element。它会自动选择系统中可用的、优先级最高的视频输出后端来渲染画面。工作逻辑它会按顺序尝试诸如ximagesinkX Window系统、fbdevsink帧缓冲设备、waylandsinkWayland、kmsKernel Mode Setting等sink。在无桌面环境的嵌入式系统上它通常会回退到fbdevsink或kmssink。为什么用它简化命令无需关心底层具体的显示接口。对于初步测试非常友好。进阶调试如果autovideosink无法正常显示可以手动指定sink来排查问题。例如使用gst-launch-1.0 ... ! kmssink来强制使用KMS驱动或者gst-launch-1.0 ... ! fbdevsink device/dev/fb0指定帧缓冲设备。3.2 执行、观察与问题排查在串口终端中输入上述命令并回车。理想情况下你应该能在连接的显示器上看到视频画面开始播放。但是你可能会遇到“有画无声”的情况正如原文标题所提示的。这是因为我们的管道只处理了视频流音频流被decodebin解码后因为没有连接音频sink如autoaudiosink就被丢弃了。这是一个非常典型的测试场景先单独验证视频通路。如果连画面都没有可以按照以下步骤排查检查GStreamer插件运行gst-inspect-1.0 | grep sunxi查看是否有全志相关的插件如sunxisink,sunxifbsink等。运行gst-inspect-1.0 decodebin确保解码器插件可用。增加调试信息在命令前加上GST_DEBUG*:2环境变量可以输出详细的调试日志看到管道构建、协商、数据流动的每一个步骤对于定位问题极其有用。GST_DEBUG*:2 gst-launch-1.0 filesrc location/talowe_test/jj.mp4 ! decodebin ! videoconvert ! autovideosink检查显示驱动通过cat /proc/fb或ls /dev/fb*查看帧缓冲设备。通过dmesg | grep -i drm或cat /sys/kernel/debug/dri/0/state如果debugfs已挂载查看DRM驱动状态。尝试指定sink如果autovideosink不行尝试手动指定# 尝试KMS sink gst-launch-1.0 filesrc location/talowe_test/jj.mp4 ! decodebin ! videoconvert ! kmssink # 尝试FBDEV sink gst-launch-1.0 filesrc location/talowe_test/jj.mp4 ! decodebin ! videoconvert ! fbdevsink device/dev/fb0检查文件格式使用gst-discoverer-1.0 /talowe_test/jj.mp4分析文件的具体编码信息确认是否被系统支持。实操心得在嵌入式平台视频播放的首个障碍往往是显示sink的选择。autovideosink虽方便但出问题时手动指定kmssink或fbdevsink是更可靠的排查方法。另外确保系统内存特别是CMA预留内存充足高清视频解码需要较大的连续内存块。4. 音频子系统测试与精细控制音频测试比视频更“玄学”因为它涉及输入录音、输出播放、路由混音多个环节且硬件差异板载麦克风、耳机麦克风会导致配置不同。ALSA是整个音频测试的基石。4.1 理解ALSA与音频设备编号在Linux中音频硬件通过ALSA驱动暴露给用户空间。每个音频设备都有一个唯一的标识。通过aplay -l和arecord -l可以列出所有播放和录制设备。# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: audiocodec [audiocodec], device 0: SUNXI-CODEC snd-soc-dummy-dai-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0这里我们看到一个声卡card 0设备device 0。在后续的命令中-D hw:0,0指的就是使用card 0, device 0。hw:表示直接访问硬件不经过任何插件重采样或转换。4.2 录音测试从麦克风到WAV文件录音的核心是配置正确的音频输入通路然后使用arecord抓取PCM数据并封装成文件。4.2.1 板载麦克风录音板载麦克风通常焊接在板上丝印为“MIC”。录音前需要通过tinymix设置音频编解码器Codec的内部路由告诉它“请把板载麦克风MIC3的信号路由到ADC模数转换器的第三个通道并且把增益开关打开。”原文给出的命令序列正是做这件事tinymix -D 0 set MIC1 Input Select 0 tinymix -D 0 set MIC2 Input Select 0 tinymix -D 0 set MIC3 Input Select 1 tinymix -D 0 set ADC1 Input MIC1 Boost Switch 0 tinymix -D 0 set ADC2 Input MIC2 Boost Switch 0 tinymix -D 0 set ADC3 Input MIC3 Boost Switch 1-D 0: 指定操作第0个声卡。set “MICx Input Select”: 这个控件选择麦克风输入的来源。值0通常表示“关闭”或“接地”值1表示连接到对应的麦克风引脚。这里只打开了MIC3。set “ADCx Input MICx Boost Switch”: 这个控件是麦克风输入到ADC通道的增益放大器开关。打开它设为1才能将麦克风的模拟信号放大并送入ADC进行数字化。这里只打开了ADC3对应MIC3的开关。为什么这么配这完全取决于T113-i评估板的硬件设计。板载麦克风物理上连接到了Codec芯片的MIC3引脚和ADC3通道。所以我们只需要启用这一路。其他路MIC1/MIC2, ADC1/ADC2关闭避免引入噪声或干扰。配置好通路后开始录音arecord -Dhw:0,0 -d 10 -f dat -r 44100 -c 1 -t wav record.wav-D hw:0,0: 使用硬件设备card 0, device 0。-d 10: 录制时长10秒。-f dat: 采样格式。dat是S16_LE有符号16位小端序的别名这是最常用的PCM格式。-r 44100: 采样率44.1kHzCD音质标准。-c 1: 单声道Mono。板载麦克风通常是单声道。-t wav: 文件类型为WAV。arecord会自动在PCM数据前加上WAV文件头。录制完成后用aplay播放来验证aplay -Dhw:0,0 -r 44100 -f S16_LE -c 1 record.wav播放时不需要指定时长(-d)它会播放整个文件。-f S16_LE明确指定了格式与录制时一致。4.2.2 耳机麦克风录音当你插入带麦克风的耳机到“AUDIOOUT”口时麦克风信号通常走的是另一路例如MIC2。因此混音器配置需要改变tinymix -D 0 set MIC1 Input Select 0 tinymix -D 0 set MIC2 Input Select 1 # 启用耳机麦克风通路 tinymix -D 0 set MIC3 Input Select 0 # 关闭板载麦克风 tinymix -D 0 set ADC2 Input MIC2 Boost Switch 1 # 打开耳机麦的ADC增益 tinymix -D 0 set ADC3 Input MIC3 Boost Switch 0 # 关闭板载麦的ADC增益这里的关键是知道硬件映射关系。不同的开发板设计耳机麦克风可能接到不同的MIC和ADC引脚上。最可靠的方法是查阅开发板的原理图或音频Codec的数据手册。如果配置不对录音会是静音或全是噪声。注意事项tinymix的控件名称和取值范围因不同的Codec驱动而异。使用tinymix -D 0命令可以列出当前声卡所有可用的控件及其当前值。这是调试音频通路最重要的工具通过对比录音前和播放前的控件状态可以快速定位问题。4.3 播放测试与系统音量控制播放相对简单除了用aplay播放自己录的文件还可以用系统自带的测试脚本快速检查扬声器和耳机输出是否正常。/talowe_test/test_audio.sh这个脚本内部很可能也是调用了aplay播放一段固定的测试音如正弦波、白噪声或一段语音。它能帮你快速判断音频输出硬件和驱动是否基本工作。音量控制是音频调试的另一大块分为交互式和脚本式。交互式控制 (alsamixer) 在终端输入alsamixer会进入一个图形界面。你可以看到多个滑动条Playback和捕获条Capture。使用左右方向键选择不同的控制器上下方向键调整音量M键静音/取消静音。Master/PCM: 主音量或PCM播放音量通常控制数字音量。Headphone: 耳机输出音量。Speaker或LINEOUT: 扬声器或线路输出音量。Capture: 录音输入音量麦克风增益。 在这里你可以直观地看到所有通路的状态并确保没有通道被静音显示MM表示静音OO表示开启。命令行/脚本控制 (amixer) 在自动化测试或产品初始化脚本中我们使用amixer。扬声器控制# 关闭扬声器 amixer -D hw:audiocodec cset nameLINEOUT Switch off # 打开扬声器 amixer -D hw:audiocodec cset nameLINEOUT Switch on # 设置扬声器音量 (0~31) amixer -D hw:audiocodec cset nameLINEOUT volume 15耳机控制# 关闭耳机输出 amixer -D hw:audiocodec cset nameHeadphone Switch off # 打开耳机输出 amixer -D hw:audiocodec cset nameHeadphone Switch on # 设置耳机音量 (0~7) amixer -D hw:audiocodec cset nameHeadphone volume 5参数解析-D hw:audiocodec: 指定声卡名称。这里用的是audiocodec与aplay -l显示的名称对应。有时直接用hw:0也可以。cset: 设置控件值。name’控件的名字’: 控件的名称必须完全匹配。可以通过amixer -D hw:audiocodec controls查看所有可用控件。off/on或 具体数值 设置的值。实操心得音频问题排查务必遵循“从硬到软从简到繁”的顺序。先确保耳机/喇叭已正确插入且硬件完好然后通过alsamixer检查是否有通道被静音或音量极低接着用tinymix确认输入输出通路配置正确最后再用arecord/aplay进行测试。tinymix和amixer的控件名是最大的变数不同内核版本或驱动版本可能会有差异一定要用命令查询确认。5. 音视频复合测试与进阶调试在分别验证了视频和音频的基本功能后更实际的场景是需要它们协同工作比如播放一个既有画面又有声音的MP4文件。此外我们还需要一些进阶手段来定位复杂问题。5.1 完整的音视频播放测试要让之前“有画无声”的视频播放出声音我们需要在GStreamer管道中同时处理视频和音频流。这需要用到decodebin的自动多路复用Demux和tee或queue等元素进行流分流。一个标准的播放命令如下gst-launch-1.0 filesrc location/talowe_test/jj.mp4 ! decodebin namedemux \ demux. ! queue ! videoconvert ! autovideosink \ demux. ! queue ! audioconvert ! audioresample ! autoaudiosinkdecodebin namedemux: 给decodebin起个名字叫demux方便后面引用它的输出。分流decodebin解码后会输出多路流视频、音频甚至字幕。我们用demux.来连接这些流。第一个demux.默认连接到视频流第二个demux.连接到音频流。queue: 在分支管道中插入队列元素是GStreamer的良好实践。它为每一路流提供一个缓冲区防止因为视频和音频处理速度不一致音画不同步而导致管道阻塞或死锁。音频处理链audioconvert类似于videoconvert用于转换音频样本格式例如从S32到S16。audioresample用于转换采样率例如从48kHz到44.1kHz以匹配音频硬件的能力。autoaudiosink会自动选择ALSA、PulseAudio等后端进行播放。执行这个命令你应该能同时看到画面和听到声音。如果只有画面没声音问题就集中在音频通路上。5.2 音频通路进阶排查如果复合播放时无声而单独的aplay测试正常问题可能出在GStreamer的音频sink或ALSA设备映射上。检查GStreamer的ALSA插件运行gst-inspect-1.0 | grep alsa确认alsasink插件存在。然后可以尝试用alsasink替代autoaudiosink并直接指定设备gst-launch-1.0 filesrc location/talowe_test/jj.mp4 ! decodebin namedemux \ demux. ! queue ! videoconvert ! kmssink \ demux. ! queue ! audioconvert ! audioresample ! alsasink devicehw:0,0检查ALSA默认设备有时autoaudiosink会选择错误的默认设备。可以通过设置环境变量来指定# 设置默认播放设备 export ALSA_PCM_CARD0 export ALSA_PCM_DEVICE0 gst-launch-1.0 ... ! autoaudiosink使用gst-discoverer和gst-launch的详细输出# 分析文件 gst-discoverer-1.0 /talowe_test/jj.mp4 -v # 运行管道并打印能力协商信息 GST_DEBUG*:4 gst-launch-1.0 ... 21 | grep -i audio从输出中可以看到音频流的详细信息编码格式、采样率、声道数以及管道在音频部分最终选择了哪个sink和什么格式。5.3 性能监控与优化提示在嵌入式设备上播放高清视频需要关注CPU和内存占用。查看CPU占用在播放视频时在另一个终端使用top或htop命令。观察gst-launch-1.0进程的CPU使用率。如果接近100%说明软件解码负担很重。T113-i的H.264解码应该是通过CedarX VPU硬件加速的但如果GStreamer没有使用正确的硬件解码插件如libav的h264_sunxi或特定的sunxidec就会退回到CPU软解导致卡顿。确认硬件加速为了确保使用了硬件解码可以尝试使用更明确的管道。这需要你确认系统中安装了对应的GStreamer硬件解码插件。例如全志平台可能有特定的sunxidec插件gst-launch-1.0 filesrc location/talowe_test/jj.mp4 ! qtdemux namedemux \ demux.video_0 ! h264parse ! sunxidec ! videoconvert ! kmssink \ demux.audio_0 ! aacparse ! faad ! audioconvert ! audioresample ! autoaudiosink这个管道使用qtdemux解复用MP4容器h264parse解析H.264流然后交给sunxidec进行硬件解码。音频流则用faad软件解码AAC。这种方式性能更高但插件依赖性强。内存与显存使用free -m查看内存使用。视频解码尤其是硬件解码会占用较多的CMA连续内存分配器内存。如果内存不足可能导致解码失败或系统卡死。确保内核配置中为CMA预留了足够的内存例如128MB或256MB。6. 常见问题速查与实战心得在调试T113-i音视频功能时我遇到了不少典型问题。这里整理成一个速查表方便大家遇到问题时快速定位。问题现象可能原因排查步骤与解决方案视频播放无画面1. 显示驱动未加载或配置错误。2. GStreamer视频sink选择错误。3. 视频文件格式不支持。4. 内存不足解码失败。1.dmesg | grep -i drm或cat /proc/fb检查显示状态。2. 尝试指定kmssink或fbdevsink。3. 使用gst-discoverer-1.0分析文件确认解码器插件存在 (gst-inspect-1.0 | grep h264)。4.free -m查看内存尝试播放更低分辨率视频。视频播放有画面但卡顿1. CPU软解负载过高。2. 未启用硬件解码。3. 显示刷新率或缓冲区设置问题。1.top查看CPU占用。如果gst-launch进程CPU很高是软解。2. 尝试使用明确的硬件解码管道如sunxidec。3. 给sink添加属性如kmssink syncfalse可能丢帧但更流畅或调整max-lateness等队列参数。音频播放无声单独aplay测试1. 音量被静音或调至最低。2. 音频输出通路未开启如扬声器开关。3. 物理连接问题耳机未插紧喇叭损坏。4. 错误的ALSA设备。1. 运行alsamixer检查Master,PCM,Headphone,Speaker等通道音量及静音状态。2. 使用amixer命令确保对应开关为on。3. 更换耳机/喇叭测试。4.aplay -L和aplay -l查看设备列表尝试-D plughw:0,0。录音无声arecord测试1. 麦克风通路未配置tinymix设置错误。2. 录音输入增益Capture为0或被静音。3. 硬件麦克风损坏或连接错误。4. 使用了错误的声卡或设备。1.tinymix -D 0查看所有控件确保对应MICx Input Select和ADCx Input MICx Boost Switch已正确打开。2. 在alsamixer中调整Capture音量取消静音按空格键。3. 尝试用耳机麦克风对比测试。4.arecord -l确认设备尝试-D hw:1,0如果有多个声卡。GStreamer播放有画无声1. 管道中未连接音频sink。2.autoaudiosink选择了错误的输出设备。3. 音频流格式采样率/声道数硬件不支持。1. 确保管道包含类似! autoaudiosink的分支。2. 改用alsasink devicehw:0,0明确指定设备。3. 在音频链中加入audioresample和audioconvert进行重采样和格式转换。使用GST_DEBUG*:2查看详细的格式协商过程。音画不同步视频和音频处理速度不一致缓冲区设置不当。1. 在视频和音频分支的decodebin后都加上! queue。2. 尝试给autovideosink或kmssink添加syncfalse属性视频追赶音频可能丢帧。3. 对于硬件解码有时需要调整解码器的输出缓冲区大小这可能需要修改GStreamer插件参数或内核驱动。tinymix或amixer找不到控件内核音频驱动版本或Codec型号不同控件名称有差异。这是最常遇到的问题不要死记硬背命令。首先执行tinymix -D 0或amixer -D hw:0 controls列出所有可用控件及其当前值。根据输出寻找类似功能的控件名如‘Lineout Switch’可能替代‘LINEOUT Switch’。最后分享几个踩坑后总结的心得文档与代码结合全志的SDK文档有时会过时。最准确的配置参考是内核源码中的设备树*.dts文件和Codec驱动代码sound/soc/sunxi/目录下。查看这些文件能知道麦克风、耳机口具体连接到了哪个引脚对应的控件名是什么。固件与驱动匹配音频Codec有时需要加载特定的固件文件*.bin。确保/lib/firmware/目录下有正确的固件并检查内核启动日志 (dmesg) 是否有加载失败的错误。测试顺序先音频后视频再复合。音频问题相对独立先用aplay/arecord这种底层工具测试能排除ALSA层面以上的所有问题GStreamer、应用层。ALSA通了上层问题就好办了。善用调试工具GST_DEBUG是GStreamer调试的瑞士军刀从1只显示错误到9海量信息能帮你看到管道构建、数据流的每一个细节。alsactl可以保存和恢复混音器设置对于产品固化音量配置非常有用。硬件差异是最大的变量我提供的tinymix命令是基于特定型号的EVM评估板。你的板子可能完全不同。务必以tinymix -D 0的实际输出为准理解每个控件的含义有的驱动代码注释很好然后根据原理图进行配置。
全志T113-i音视频开发实战：从GStreamer播放到ALSA音频配置详解
1. 项目概述与核心价值最近在折腾一块全志T113-i的开发板主要想用它来跑一些音视频相关的应用。说实话嵌入式音视频开发的门槛不低从硬件接口、驱动配置到上层应用调试每一步都可能遇到意想不到的坑。网上能找到的资料要么太零散要么就是官方文档那种“只告诉你做什么不告诉你为什么”的风格真到动手的时候还是两眼一抹黑。所以我花了些时间把T113-i这块板子上音视频功能的完整测试流程从底层配置到上层命令都系统地走了一遍并且把过程中的关键原理、操作细节和踩过的坑都记录了下来。这篇文章就是这份实战笔记的整理希望能帮到同样在T113-i平台上进行音视频开发的同行们让大家能快速上手把宝贵的精力用在业务逻辑上而不是在基础功能验证上反复折腾。全志T113-i这颗SoC集成了双核Cortex-A7 CPU和一个HiFi4 DSP在多媒体处理上有着不错的潜力。它支持多种视频编解码格式和音频接口但潜力要转化为实际能力离不开正确的配置和调试。无论是想验证板子的音视频输出是否正常还是为后续的摄像头采集、流媒体播放、语音对讲等应用打基础一套清晰、可复现的测试方法都是必不可少的。接下来我会从最基础的视频播放测试开始逐步深入到音频的录制、播放、混音配置和音量控制不仅告诉你命令怎么敲更会解释每个参数背后的含义以及在不同场景下该如何调整。如果你是嵌入式Linux的初学者可以跟着步骤一步步操作如果你是有经验的开发者也可以直接跳到感兴趣的章节参考其中的配置思路和问题排查方法。2. 测试环境搭建与前期准备2.1 硬件连接与确认在开始任何软件操作之前确保硬件连接正确是第一步这能避免很多“灵异”问题。我使用的是眺望电子的EVM-T113-i评估板。你需要准备以下东西开发板EVM-T113-i主板。电源使用配套的12V/2A电源适配器稳定供电是基础。显示设备板子带有HDMI接口准备一根HDMI线连接至显示器或电视。有些板子也可能支持RGB/LVDS屏需要根据你的具体板型连接对应的屏幕。音频设备扬声器板载有扬声器输出接口通常标记为SPK和SPK-可以连接一个小喇叭。更常见的是通过HDMI输出音频到显示器。耳机/麦克风准备一个3.5mm接口的耳机带麦克风功能的最佳插入板子上标记为“AUDIOOUT”的3.5mm复合音频接口。这个接口既支持音频输出耳机听也支持音频输入麦克风录。存储介质准备一个TF卡用于存放测试用的视频和音频文件。将板子启动并挂载TF卡后文件通常位于/mnt/或/media/目录下。我建议在TF卡根目录创建一个talowe_test文件夹把所有测试文件放进去方便管理。串口调试工具这是嵌入式开发的“生命线”。通过USB转TTL串口线连接板子的调试串口通常是UART0使用MobaXterm、SecureCRT或Minicom等工具设置波特率为115200进行命令行操作和日志查看。注意首次上电或更换屏幕后如果无显示先检查电源指示灯是否正常然后通过串口查看内核启动日志确认DRMDirect Rendering Manager驱动是否成功加载并识别了显示设备。有时需要根据屏幕型号修改设备树Device Tree中的显示参数。2.2 软件系统与工具链测试基于板子预装的Linux系统通常是基于Buildroot或Yocto定制的。你需要确认系统中已包含以下关键工具和组件如果缺少可能需要重新构建根文件系统镜像。GStreamer这是进行视频播放测试的核心多媒体框架。我们需要用到其命令行工具gst-launch-1.0。通过串口执行gst-launch-1.0 --version来确认其是否存在及版本。T113-i平台通常会使用GStreamer的sunxi插件集其中包含了针对全志芯片优化的编解码器。ALSAAdvanced Linux Sound Architecture工具集这是Linux音频子系统的核心。我们需要用到tinymix: 一个轻量级的混音器控制工具用于配置音频通路如选择哪个麦克风输入、调整增益。arecord/aplay: 分别用于录制和播放PCM脉冲编码调制格式的原始音频文件。alsamixer: 一个基于ncurses的图形化混音器界面方便交互式调整音量。amixer:alsamixer的命令行版本适合用于脚本中的音量控制。 可以通过tinymix -h和arecord --version来检查这些工具是否可用。测试文件视频文件准备一个常见的视频文件如jj.mp4H.264编码AAC音频。将其拷贝到TF卡的talowe_test目录下。如果系统自带测试文件路径可能已在/talowe_test/下。音频脚本系统可能自带一个测试脚本如/talowe_test/test_audio.sh它会播放一段预置的测试音效用于快速验证音频输出通路是否畅通。确保你通过串口登录到开发板的Linux系统并拥有root权限通常提示符为#因为很多音频设备的操作需要高权限。3. 视频播放测试全流程解析视频播放是验证显示系统和解码能力最直观的方式。在嵌入式Linux中我们通常使用GStreamer这个强大的管道式多媒体框架。下面这个命令看似简单但每一个环节都值得深究。3.1 核心命令深度拆解输入的命令是gst-launch-1.0 filesrc location/talowe_test/jj.mp4 ! decodebin ! videoconvert ! autovideosink这条命令构建了一个GStreamer处理管道Pipeline。我们把它拆开来看filesrc location/talowe_test/jj.mp4作用源元素Source Element。它从指定位置/talowe_test/jj.mp4读取原始数据流。为什么用它这是最直接的本地文件读取方式。除了filesrc还可以用httpsrc处理网络流v4l2src处理摄像头采集。这里我们测试本地文件所以用filesrc。注意事项确保路径正确且文件有读取权限。如果文件不存在或路径错误GStreamer会报错“找不到文件”。路径中的talowe_test是我举例的目录请替换为你实际的路径。! decodebin作用解码器容器Decoder Bin。它是一个智能元素会自动检测输入流的容器格式如MP4和编码格式如H.264视频AAC音频然后动态创建并连接对应的解码器插件如avdec_h264用于视频faad用于音频。为什么用它省去了我们手动指定具体解码器的麻烦尤其当不确定文件编码格式时非常有用。它会输出原始的、解码后的视频帧和音频样本。关键点decodebin是异步的。当它连接到下游元素如videoconvert时会尝试进行能力协商Caps Negotiation。如果系统里没有对应的解码器插件管道会失败。对于T113-i确保已安装gstreamer1.0-plugins-good,-bad,-ugly包含更多编解码器以及全志提供的gstreamer1.0-sunxi插件。! videoconvert作用视频格式转换器。它将解码器输出的原始视频帧可能是YUV420, NV12, RGB等格式转换为下游sink元素这里是autovideosink所支持的格式。为什么需要它不同的硬件加速后端或显示接口对输入图像格式有严格要求。例如某些直接渲染的sink可能只接受特定的RGB或YUV排列。videoconvert在软件层面进行格式转换保证了管道的通用性。性能考量这是一个纯软件转换会消耗一定的CPU资源。在追求极致性能的场景下如果确定解码器输出格式与sink需求完全匹配可以尝试省略它。但作为通用测试加上它能避免很多因格式不匹配导致的绿屏或花屏问题。! autovideosink作用自动视频输出器Sink Element。它会自动选择系统中可用的、优先级最高的视频输出后端来渲染画面。工作逻辑它会按顺序尝试诸如ximagesinkX Window系统、fbdevsink帧缓冲设备、waylandsinkWayland、kmsKernel Mode Setting等sink。在无桌面环境的嵌入式系统上它通常会回退到fbdevsink或kmssink。为什么用它简化命令无需关心底层具体的显示接口。对于初步测试非常友好。进阶调试如果autovideosink无法正常显示可以手动指定sink来排查问题。例如使用gst-launch-1.0 ... ! kmssink来强制使用KMS驱动或者gst-launch-1.0 ... ! fbdevsink device/dev/fb0指定帧缓冲设备。3.2 执行、观察与问题排查在串口终端中输入上述命令并回车。理想情况下你应该能在连接的显示器上看到视频画面开始播放。但是你可能会遇到“有画无声”的情况正如原文标题所提示的。这是因为我们的管道只处理了视频流音频流被decodebin解码后因为没有连接音频sink如autoaudiosink就被丢弃了。这是一个非常典型的测试场景先单独验证视频通路。如果连画面都没有可以按照以下步骤排查检查GStreamer插件运行gst-inspect-1.0 | grep sunxi查看是否有全志相关的插件如sunxisink,sunxifbsink等。运行gst-inspect-1.0 decodebin确保解码器插件可用。增加调试信息在命令前加上GST_DEBUG*:2环境变量可以输出详细的调试日志看到管道构建、协商、数据流动的每一个步骤对于定位问题极其有用。GST_DEBUG*:2 gst-launch-1.0 filesrc location/talowe_test/jj.mp4 ! decodebin ! videoconvert ! autovideosink检查显示驱动通过cat /proc/fb或ls /dev/fb*查看帧缓冲设备。通过dmesg | grep -i drm或cat /sys/kernel/debug/dri/0/state如果debugfs已挂载查看DRM驱动状态。尝试指定sink如果autovideosink不行尝试手动指定# 尝试KMS sink gst-launch-1.0 filesrc location/talowe_test/jj.mp4 ! decodebin ! videoconvert ! kmssink # 尝试FBDEV sink gst-launch-1.0 filesrc location/talowe_test/jj.mp4 ! decodebin ! videoconvert ! fbdevsink device/dev/fb0检查文件格式使用gst-discoverer-1.0 /talowe_test/jj.mp4分析文件的具体编码信息确认是否被系统支持。实操心得在嵌入式平台视频播放的首个障碍往往是显示sink的选择。autovideosink虽方便但出问题时手动指定kmssink或fbdevsink是更可靠的排查方法。另外确保系统内存特别是CMA预留内存充足高清视频解码需要较大的连续内存块。4. 音频子系统测试与精细控制音频测试比视频更“玄学”因为它涉及输入录音、输出播放、路由混音多个环节且硬件差异板载麦克风、耳机麦克风会导致配置不同。ALSA是整个音频测试的基石。4.1 理解ALSA与音频设备编号在Linux中音频硬件通过ALSA驱动暴露给用户空间。每个音频设备都有一个唯一的标识。通过aplay -l和arecord -l可以列出所有播放和录制设备。# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: audiocodec [audiocodec], device 0: SUNXI-CODEC snd-soc-dummy-dai-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0这里我们看到一个声卡card 0设备device 0。在后续的命令中-D hw:0,0指的就是使用card 0, device 0。hw:表示直接访问硬件不经过任何插件重采样或转换。4.2 录音测试从麦克风到WAV文件录音的核心是配置正确的音频输入通路然后使用arecord抓取PCM数据并封装成文件。4.2.1 板载麦克风录音板载麦克风通常焊接在板上丝印为“MIC”。录音前需要通过tinymix设置音频编解码器Codec的内部路由告诉它“请把板载麦克风MIC3的信号路由到ADC模数转换器的第三个通道并且把增益开关打开。”原文给出的命令序列正是做这件事tinymix -D 0 set MIC1 Input Select 0 tinymix -D 0 set MIC2 Input Select 0 tinymix -D 0 set MIC3 Input Select 1 tinymix -D 0 set ADC1 Input MIC1 Boost Switch 0 tinymix -D 0 set ADC2 Input MIC2 Boost Switch 0 tinymix -D 0 set ADC3 Input MIC3 Boost Switch 1-D 0: 指定操作第0个声卡。set “MICx Input Select”: 这个控件选择麦克风输入的来源。值0通常表示“关闭”或“接地”值1表示连接到对应的麦克风引脚。这里只打开了MIC3。set “ADCx Input MICx Boost Switch”: 这个控件是麦克风输入到ADC通道的增益放大器开关。打开它设为1才能将麦克风的模拟信号放大并送入ADC进行数字化。这里只打开了ADC3对应MIC3的开关。为什么这么配这完全取决于T113-i评估板的硬件设计。板载麦克风物理上连接到了Codec芯片的MIC3引脚和ADC3通道。所以我们只需要启用这一路。其他路MIC1/MIC2, ADC1/ADC2关闭避免引入噪声或干扰。配置好通路后开始录音arecord -Dhw:0,0 -d 10 -f dat -r 44100 -c 1 -t wav record.wav-D hw:0,0: 使用硬件设备card 0, device 0。-d 10: 录制时长10秒。-f dat: 采样格式。dat是S16_LE有符号16位小端序的别名这是最常用的PCM格式。-r 44100: 采样率44.1kHzCD音质标准。-c 1: 单声道Mono。板载麦克风通常是单声道。-t wav: 文件类型为WAV。arecord会自动在PCM数据前加上WAV文件头。录制完成后用aplay播放来验证aplay -Dhw:0,0 -r 44100 -f S16_LE -c 1 record.wav播放时不需要指定时长(-d)它会播放整个文件。-f S16_LE明确指定了格式与录制时一致。4.2.2 耳机麦克风录音当你插入带麦克风的耳机到“AUDIOOUT”口时麦克风信号通常走的是另一路例如MIC2。因此混音器配置需要改变tinymix -D 0 set MIC1 Input Select 0 tinymix -D 0 set MIC2 Input Select 1 # 启用耳机麦克风通路 tinymix -D 0 set MIC3 Input Select 0 # 关闭板载麦克风 tinymix -D 0 set ADC2 Input MIC2 Boost Switch 1 # 打开耳机麦的ADC增益 tinymix -D 0 set ADC3 Input MIC3 Boost Switch 0 # 关闭板载麦的ADC增益这里的关键是知道硬件映射关系。不同的开发板设计耳机麦克风可能接到不同的MIC和ADC引脚上。最可靠的方法是查阅开发板的原理图或音频Codec的数据手册。如果配置不对录音会是静音或全是噪声。注意事项tinymix的控件名称和取值范围因不同的Codec驱动而异。使用tinymix -D 0命令可以列出当前声卡所有可用的控件及其当前值。这是调试音频通路最重要的工具通过对比录音前和播放前的控件状态可以快速定位问题。4.3 播放测试与系统音量控制播放相对简单除了用aplay播放自己录的文件还可以用系统自带的测试脚本快速检查扬声器和耳机输出是否正常。/talowe_test/test_audio.sh这个脚本内部很可能也是调用了aplay播放一段固定的测试音如正弦波、白噪声或一段语音。它能帮你快速判断音频输出硬件和驱动是否基本工作。音量控制是音频调试的另一大块分为交互式和脚本式。交互式控制 (alsamixer) 在终端输入alsamixer会进入一个图形界面。你可以看到多个滑动条Playback和捕获条Capture。使用左右方向键选择不同的控制器上下方向键调整音量M键静音/取消静音。Master/PCM: 主音量或PCM播放音量通常控制数字音量。Headphone: 耳机输出音量。Speaker或LINEOUT: 扬声器或线路输出音量。Capture: 录音输入音量麦克风增益。 在这里你可以直观地看到所有通路的状态并确保没有通道被静音显示MM表示静音OO表示开启。命令行/脚本控制 (amixer) 在自动化测试或产品初始化脚本中我们使用amixer。扬声器控制# 关闭扬声器 amixer -D hw:audiocodec cset nameLINEOUT Switch off # 打开扬声器 amixer -D hw:audiocodec cset nameLINEOUT Switch on # 设置扬声器音量 (0~31) amixer -D hw:audiocodec cset nameLINEOUT volume 15耳机控制# 关闭耳机输出 amixer -D hw:audiocodec cset nameHeadphone Switch off # 打开耳机输出 amixer -D hw:audiocodec cset nameHeadphone Switch on # 设置耳机音量 (0~7) amixer -D hw:audiocodec cset nameHeadphone volume 5参数解析-D hw:audiocodec: 指定声卡名称。这里用的是audiocodec与aplay -l显示的名称对应。有时直接用hw:0也可以。cset: 设置控件值。name’控件的名字’: 控件的名称必须完全匹配。可以通过amixer -D hw:audiocodec controls查看所有可用控件。off/on或 具体数值 设置的值。实操心得音频问题排查务必遵循“从硬到软从简到繁”的顺序。先确保耳机/喇叭已正确插入且硬件完好然后通过alsamixer检查是否有通道被静音或音量极低接着用tinymix确认输入输出通路配置正确最后再用arecord/aplay进行测试。tinymix和amixer的控件名是最大的变数不同内核版本或驱动版本可能会有差异一定要用命令查询确认。5. 音视频复合测试与进阶调试在分别验证了视频和音频的基本功能后更实际的场景是需要它们协同工作比如播放一个既有画面又有声音的MP4文件。此外我们还需要一些进阶手段来定位复杂问题。5.1 完整的音视频播放测试要让之前“有画无声”的视频播放出声音我们需要在GStreamer管道中同时处理视频和音频流。这需要用到decodebin的自动多路复用Demux和tee或queue等元素进行流分流。一个标准的播放命令如下gst-launch-1.0 filesrc location/talowe_test/jj.mp4 ! decodebin namedemux \ demux. ! queue ! videoconvert ! autovideosink \ demux. ! queue ! audioconvert ! audioresample ! autoaudiosinkdecodebin namedemux: 给decodebin起个名字叫demux方便后面引用它的输出。分流decodebin解码后会输出多路流视频、音频甚至字幕。我们用demux.来连接这些流。第一个demux.默认连接到视频流第二个demux.连接到音频流。queue: 在分支管道中插入队列元素是GStreamer的良好实践。它为每一路流提供一个缓冲区防止因为视频和音频处理速度不一致音画不同步而导致管道阻塞或死锁。音频处理链audioconvert类似于videoconvert用于转换音频样本格式例如从S32到S16。audioresample用于转换采样率例如从48kHz到44.1kHz以匹配音频硬件的能力。autoaudiosink会自动选择ALSA、PulseAudio等后端进行播放。执行这个命令你应该能同时看到画面和听到声音。如果只有画面没声音问题就集中在音频通路上。5.2 音频通路进阶排查如果复合播放时无声而单独的aplay测试正常问题可能出在GStreamer的音频sink或ALSA设备映射上。检查GStreamer的ALSA插件运行gst-inspect-1.0 | grep alsa确认alsasink插件存在。然后可以尝试用alsasink替代autoaudiosink并直接指定设备gst-launch-1.0 filesrc location/talowe_test/jj.mp4 ! decodebin namedemux \ demux. ! queue ! videoconvert ! kmssink \ demux. ! queue ! audioconvert ! audioresample ! alsasink devicehw:0,0检查ALSA默认设备有时autoaudiosink会选择错误的默认设备。可以通过设置环境变量来指定# 设置默认播放设备 export ALSA_PCM_CARD0 export ALSA_PCM_DEVICE0 gst-launch-1.0 ... ! autoaudiosink使用gst-discoverer和gst-launch的详细输出# 分析文件 gst-discoverer-1.0 /talowe_test/jj.mp4 -v # 运行管道并打印能力协商信息 GST_DEBUG*:4 gst-launch-1.0 ... 21 | grep -i audio从输出中可以看到音频流的详细信息编码格式、采样率、声道数以及管道在音频部分最终选择了哪个sink和什么格式。5.3 性能监控与优化提示在嵌入式设备上播放高清视频需要关注CPU和内存占用。查看CPU占用在播放视频时在另一个终端使用top或htop命令。观察gst-launch-1.0进程的CPU使用率。如果接近100%说明软件解码负担很重。T113-i的H.264解码应该是通过CedarX VPU硬件加速的但如果GStreamer没有使用正确的硬件解码插件如libav的h264_sunxi或特定的sunxidec就会退回到CPU软解导致卡顿。确认硬件加速为了确保使用了硬件解码可以尝试使用更明确的管道。这需要你确认系统中安装了对应的GStreamer硬件解码插件。例如全志平台可能有特定的sunxidec插件gst-launch-1.0 filesrc location/talowe_test/jj.mp4 ! qtdemux namedemux \ demux.video_0 ! h264parse ! sunxidec ! videoconvert ! kmssink \ demux.audio_0 ! aacparse ! faad ! audioconvert ! audioresample ! autoaudiosink这个管道使用qtdemux解复用MP4容器h264parse解析H.264流然后交给sunxidec进行硬件解码。音频流则用faad软件解码AAC。这种方式性能更高但插件依赖性强。内存与显存使用free -m查看内存使用。视频解码尤其是硬件解码会占用较多的CMA连续内存分配器内存。如果内存不足可能导致解码失败或系统卡死。确保内核配置中为CMA预留了足够的内存例如128MB或256MB。6. 常见问题速查与实战心得在调试T113-i音视频功能时我遇到了不少典型问题。这里整理成一个速查表方便大家遇到问题时快速定位。问题现象可能原因排查步骤与解决方案视频播放无画面1. 显示驱动未加载或配置错误。2. GStreamer视频sink选择错误。3. 视频文件格式不支持。4. 内存不足解码失败。1.dmesg | grep -i drm或cat /proc/fb检查显示状态。2. 尝试指定kmssink或fbdevsink。3. 使用gst-discoverer-1.0分析文件确认解码器插件存在 (gst-inspect-1.0 | grep h264)。4.free -m查看内存尝试播放更低分辨率视频。视频播放有画面但卡顿1. CPU软解负载过高。2. 未启用硬件解码。3. 显示刷新率或缓冲区设置问题。1.top查看CPU占用。如果gst-launch进程CPU很高是软解。2. 尝试使用明确的硬件解码管道如sunxidec。3. 给sink添加属性如kmssink syncfalse可能丢帧但更流畅或调整max-lateness等队列参数。音频播放无声单独aplay测试1. 音量被静音或调至最低。2. 音频输出通路未开启如扬声器开关。3. 物理连接问题耳机未插紧喇叭损坏。4. 错误的ALSA设备。1. 运行alsamixer检查Master,PCM,Headphone,Speaker等通道音量及静音状态。2. 使用amixer命令确保对应开关为on。3. 更换耳机/喇叭测试。4.aplay -L和aplay -l查看设备列表尝试-D plughw:0,0。录音无声arecord测试1. 麦克风通路未配置tinymix设置错误。2. 录音输入增益Capture为0或被静音。3. 硬件麦克风损坏或连接错误。4. 使用了错误的声卡或设备。1.tinymix -D 0查看所有控件确保对应MICx Input Select和ADCx Input MICx Boost Switch已正确打开。2. 在alsamixer中调整Capture音量取消静音按空格键。3. 尝试用耳机麦克风对比测试。4.arecord -l确认设备尝试-D hw:1,0如果有多个声卡。GStreamer播放有画无声1. 管道中未连接音频sink。2.autoaudiosink选择了错误的输出设备。3. 音频流格式采样率/声道数硬件不支持。1. 确保管道包含类似! autoaudiosink的分支。2. 改用alsasink devicehw:0,0明确指定设备。3. 在音频链中加入audioresample和audioconvert进行重采样和格式转换。使用GST_DEBUG*:2查看详细的格式协商过程。音画不同步视频和音频处理速度不一致缓冲区设置不当。1. 在视频和音频分支的decodebin后都加上! queue。2. 尝试给autovideosink或kmssink添加syncfalse属性视频追赶音频可能丢帧。3. 对于硬件解码有时需要调整解码器的输出缓冲区大小这可能需要修改GStreamer插件参数或内核驱动。tinymix或amixer找不到控件内核音频驱动版本或Codec型号不同控件名称有差异。这是最常遇到的问题不要死记硬背命令。首先执行tinymix -D 0或amixer -D hw:0 controls列出所有可用控件及其当前值。根据输出寻找类似功能的控件名如‘Lineout Switch’可能替代‘LINEOUT Switch’。最后分享几个踩坑后总结的心得文档与代码结合全志的SDK文档有时会过时。最准确的配置参考是内核源码中的设备树*.dts文件和Codec驱动代码sound/soc/sunxi/目录下。查看这些文件能知道麦克风、耳机口具体连接到了哪个引脚对应的控件名是什么。固件与驱动匹配音频Codec有时需要加载特定的固件文件*.bin。确保/lib/firmware/目录下有正确的固件并检查内核启动日志 (dmesg) 是否有加载失败的错误。测试顺序先音频后视频再复合。音频问题相对独立先用aplay/arecord这种底层工具测试能排除ALSA层面以上的所有问题GStreamer、应用层。ALSA通了上层问题就好办了。善用调试工具GST_DEBUG是GStreamer调试的瑞士军刀从1只显示错误到9海量信息能帮你看到管道构建、数据流的每一个细节。alsactl可以保存和恢复混音器设置对于产品固化音量配置非常有用。硬件差异是最大的变量我提供的tinymix命令是基于特定型号的EVM评估板。你的板子可能完全不同。务必以tinymix -D 0的实际输出为准理解每个控件的含义有的驱动代码注释很好然后根据原理图进行配置。
