精华内容
下载资源
问答
  • alsa子系统
    2020-12-07 16:31:57

    你好!这里是风筝的博客,

    欢迎和我一起交流。


    /proc/asound for fun and profit

    Linux倾向于将有关系统进程的信息(包括一些硬件配置信息)放在称为的虚拟文件系统中/proc。这里的项目不是实际文件,
    它们是从操作系统内核和关联的内核模块读取信息并将信息发送到操作系统内核和相关的内核模块的一种方式。

    可以通过在虚拟文件cat more less 或一些其他文件程序读取信息。通过使用cat或echo将数据写入虚拟文件来完成发送回命令。

    /proc/asound文件集是ALSA用于设备信息和某些控制的文件。

    有哪些文件?

    /proc信息诸如usb描述符转储之类的硬件依赖。内容取决于驱动程序作者,因此实际上不可能有完整的一般描述。也就是说,ALSA确实具有大多数驱动程序都遵循的某些标准。

    由ALSA本身提供的基本文件:

    • /proc/asound/cardX/(其中X是声卡号,从0到7):cardX系统知道的每个声卡都有一个目录:有关此目录内容的信息,请参见下文。

    • /proc/asound/cards (只读):已注册卡的列表

    • /proc/asound/dev/ :一个目录,列出如果系统使用devfs则程序用于声音操作的特定设备文件,该目录将存在:如果您的系统不使用devfs(从2006-06开始,大多数不使用):该文件要么不根本存在,或者仅仅是与之的符号链接 /dev/snd

    • /proc/asound/devices (只读):已注册的ALSA设备列表(主设备号= 116)

    • /proc/asound/hwdep (只读):hwdep(硬件依赖)控件的列表未在所有系统上出现(这是否仍然存在?)

    • /proc/asound/meminfo (只读):内存使用情况信息,此proc文件仅在使用内存调试(或完整)选项构建alsa驱动程序时才会显示:当前在内核空间上分配的内存。

    • /proc/asound/modules(只读):已注册的ALSA声卡驱动程序列表,这不是ALSA加载的所有内核模块,这只是:硬件驱动程序的列表。对于使用中的每个声卡,期望在此处看到一行。

    • /proc/asound/oss/ :包含有关oss仿真的信息的目录,有关此目录内容的信息,请参见下文。

    • /proc/asound/pcm(只读):分配的pcm流的列表,请注意,这(可能)并不表示活动流的列表,而是设备的列表。这对于找出hw:0,0样式的设备非常有用:像aplay这样的命令需要的名称。

    • /proc/asound/seq/ :包含有关音序器信息的目录,有关此目录内容的信息,请参见下文。

    • /proc/asound/timers(只读):类似于/proc/asound/pcm,它是ALSA知道的计时器列表,并且描述了:在该时刻实际使用了哪些计时器。

    • /proc/asound/version (只读):ALSA子系统模块(或内核)的版本和日期

    注意:上面标记为“只读”的设备仅用于提供内核信息。所有其他设备均为读写设备,可用于向ALSA发送命令。

    设备文件/dev/snd/ (和 /proc/asound/dev/)

    设备文件是应用程序连接到的文件,以便执行声音操作,例如录音,播放,更改音量,获取定时信息以及执行MIDI音序。
    通常可以在/dev/snd中找到它们,但在某些系统上也可以在/proc/asound/dev中找到它们。

    通常,设备文件以aaaCxDy的形式命名:
    aaa是服务名称
    x是卡号(0-7)
    y设备编号(0-?)

    controlC?  control devices (i.e. mixer, etc.)
    hwC?D?     hwdep devices
    midiC?D?   rawmidi devices
    pcmC?D?p   pcm playback devices
    pcmC?D?c   pcm capture devices
    seq        sequencer device
    timer      timer device
    

    /proc/asound/oss/ 目录

    此目录下文件的内容是动态更改的。 如果未加载任何oss仿真模块(snd-pcm-oss,snd-mixer-oss),则不会列出pcm或混音器设备。

    /proc/sound/cardX/ 目录

    id (RO)
     the id string of the card
    
    ac97#? (RO)
     AC97 codec information
    
    ac97#?regs (RO)
     (printable) register dump
    
    midi? (RO)
     the current status of input/output on the
     rawmidi device
    
    pcm?p
     the directory status of the given pcm playback stream
    pcm?c
     the directory status of the given pcm capture stream
    

    /proc/asound/cardX/pcmXX/ 目录

    这些可选目录中的文件包含PCM流信息。请注意,在Linux 2.6.17和更高版本中,只有在内核配置中启用了CONFIG_SND_VERBOSE_PROCFS(“详细的procfs内容”)后,这些文件才可用。

    pcm??/info (RO)
     the pcm stream general info (card, device, name, etc.)
    
    pcm??/oss (RO)
     oss emulation info (shown only when the pcm is opened
     as an oss device).
    
    pcm??/sub?
     the substream information directory
    
    pcm??/sub?/info (RO)
     the pcm substream general info (card, device, name, etc.)
    
    pcm??/sub?/status (RO)
     the current status of the given pcm substream
     (status, position, delay, tick time, etc.)
    
    pcm??/sub?/hw_params (RO)
     hw_params set-up on the substream
     (buffer size, format, etc.)
    
    pcm??/sub?/sw_params (RO)
     sw_params set-up on the substream
     (threshold, etc.)
    
    pcm??/sub?/prealloc (RW)
     the number of pre-allocated buffer size in kb.
     you can specify the buffer size by writing to this proc file:
    
     # echo 128 > /proc/asound/card0/pcm0p/sub0/prealloc
    
     to allocate 128kbyte for playback, substream #0, stream #0
     on the card #0.
    

    要查找计算机上alsa模块的所有选项,请运行以下脚本…

    modinfo $(modprobe -l snd-*) > ~/modinfo
    

    /proc/asound/seq/ 目录

    clients : Need info
    drivers : Need info
    oss : Need info
    queues : Need info
    timer : Need info

    那么,什么是硬件设备?

    典型输出如下所示:

    prompt# cat /proc/asound/devices  
      0: [ 0]   : control 
      1:        : sequencer 
     16: [ 0- 0]: digital audio playback 
     18: [ 0- 2]: digital audio playback 
     24: [ 0- 0]: digital audio capture 
     25: [ 0- 1]: digital audio capture 
     33:        : timer 
    

    上面的示例表示,有一个控制通道,两个PCM播放设备(DAC),两个PCM捕获设备(ADC),一个MIDI音序器和一个计时器。

    在此示例所使用的系统上,没有任何其他内容的重新映射,这些等同于以下内容:

    Device:

    • 第一个PCM播放DAC
    • 它的作用:播放声音
    • 设备文件如下所示:
    • crw-rw---- 1 root audio 116, 16 Mar 4 21:30 pcmC0D0p
      -(日期可能会有所不同)
    • ALSA称之为:hw:0,0的播放部分,它是一个双工设备
    • 第一个PCM录音ADC
    • 它的作用:播放声音
    • 设备文件如下所示:
    • crw-rw---- 1 root audio 116, 16 Mar 4 21:30 pcmC0D0c
    • ALSA称之为:hw:0,0的录音部分,这是一个双工设备
    • 第一个声卡的控制通道
    • 它的作用:控制音量/录音增益(和其他功能?)
      设备文件如下所示:
    • crw-rw---- 1 root audio 116, 0 Mon DD hh:mm /dev/snd/controlC0
      (Mon DD hh:mm是在系统上创建设备文件的日期和时间)

    /proc 将会改变

    将来/ proc将仅用于过程信息,查找ALSA信息的位置将是sysfs。
    在2.6内核源目录,他的文件在这:
    Documentation/filesystems/sysfs.txt

    与此有关的一些信息。 从2006-06(和内核2.6.16)开始,/ sys存在,但/ proc接口尚未更改。

    翻译:https://alsa.opensrc.org/Proc_asound_documentation#The_.2Fproc.2Fasound.2Foss.2F_directory

    更多相关内容
  • 音频子系统(ASOC框架)之Machine 音频子系统(ASOC框架)之Codec 现在回看,当时写得可真是粗糙啊,连DAPM都没涉及到,主要还是以前读书时对这些东西还是学习状态,不像现在,需要谋生。。。。。。 唉,扯远了,以前...

    你好!这里是风筝的博客,

    欢迎和我一起交流。


    之前在这篇文章:Tinyplay流程分析
    分析了tinyplay到操作,那么,我们可以继续分析下这些操作具体到底层是个什么样子!

    以前大学读书时倒是写过两篇alsa到底层驱动文章:
    音频子系统(ASOC框架)之Machine
    音频子系统(ASOC框架)之Codec

    现在回看,当时写得可真是粗糙啊,连DAPM都没涉及到,主要还是以前读书时对这些东西还是学习状态,不像现在,需要谋生。。。。。。

    唉,扯远了,以前倒是喜欢贴出代码一顿分析,不过现在越发感觉画流程图才是最好到解释方法!

    open时和设置hw_params流程如图:
    open&params

    在读写音频时,会先进行prepare操作,流程如图:
    prepare
    最后,我们进行读写音频,把数据写入缓冲区里:
    write
    至此,关键流程已给出,还是画图比贴代码方便直观。

    展开全文
  • ALSA子系统(五)------XRUN排查

    千次阅读 2020-12-07 15:16:55
    在这两种情况下,都表明系统速度不够快,未能及时处理来自ALSA音频缓冲区的数据,因此丢失了一些数据。当我们以非常小的缓冲区大小运行时,声卡应该非常快地处理传入缓冲区的数据,否则就溢出overrun了。有些芯片...

    你好!这里是风筝的博客,

    欢迎和我一起交流。


    什么是XRUN?相信做音频的童鞋都不陌生。
    它是缓冲区不足或溢出,X代表不足或溢出。在这两种情况下,都表明系统速度不够快,未能及时处理来自ALSA音频缓冲区的数据,因此丢失了一些数据。当我们以非常小的缓冲区大小运行时,声卡应该非常快地处理传入缓冲区的数据,否则就溢出overrun了。有些芯片无法适应较小的缓冲区大小,因此我们必须增加缓冲区长度以减轻声音芯片的工作量。通常,xruns可以听到爆裂声或爆裂声。

    在录音例子中,如果应用程序读取数据不够快,循环缓存区将会被新的数据覆盖。这种数据的丢失被称为"over run".
    在回放例子中,如果应用程序写入数据到缓存区中的速度不够快,缓存区将会"饿死"。这样的错误被称为"under run"。
    在ALSA文档中,有时将这两种情形统称为"XRUN"。适当地设计应用程序可以最小化XRUN并且可以从中恢复过来。

    好在ALSA提供了一种通过proc记录和调试xrun的方法:
    Menuconfig配置如下:

    Device Drivers  --->  <*> Sound card support  --->  <*>   Advanced Linux Sound Architecture  ---> [*]   Sound Proc FS Support
    
    Device Drivers  --->  <*> Sound card support  --->  <*>   Advanced Linux Sound Architecture  ---> [*]   Debug  --->  [*]     Enable PCM ring buffer overrun/underrun debugging
    

    menuconfig
    可能某些内核版本不一定路径完全一样,不过主要记住一个,我们配置里选上这些,目的就是为了使得CONFIG_SND_PCM_XRUN_DEBUG这个配置起效。
    实现文件在:sound/core/pcm_lib.c里面:

    #ifdef CONFIG_SND_PCM_XRUN_DEBUG
    
    #define xrun_debug(substream, mask) \
                            ((substream)->pstr->xrun_debug & (mask))
    #else
    #define xrun_debug(substream, mask)     0
    #endif
    

    配置好之后重新编译代码,启动系统,如果出现了XRUN,会得到类似这样的打印信息:

    audiocodec soc@xxxxxxxx:sound@0:XRUN:pcmC0D0p:0
    

    /proc配置

    XRUN主要要靠/proc下配置一些功能来查看信息,在:/proc/asound/card#/pcm0p/xrun_debug
    将“#”替换为具体卡号(通常为0)。此proc文件可以启用各种调试工具。

     1   Basic debugging - show xruns in ksyslog interface
     2   Dump stack - dump stack for basic debugging
     4   Jiffies check - compare the position with kernel jiffies (a sort of in-kernel monotonic clock),
         show what's changed when basic debugging is enabled
     8   Dump positions on each period update call
     16  Dump positions on each hardware pointer update call
     32  Enable logging of last 10 ring buffer positions
     64  Show the last 10 ring buffer position only once (when first error situation occured)
    

    要启用更多功能,只需对上述值求和(例如1 + 2 = 3)
    一些常用到好的组合如下:

    # Enable basic debugging and dump stack
    # Usefull to just see, if PCM stream is stopped for a reason (usually wrong audio process timing from scheduler)
     echo 3 > /proc/asound/card0/pcm0p/xrun_debug
    

    上面往xrun_debug写入3,也就是启用基本调试和堆栈功能(Enable basic debugging and dump stack)以及查看PCM流是否由于某种原因而停止(if PCM stream is stopped for a reason)。
    还有一些常用到组合配置:

    # Enable basic debugging and dump stack, check hardware pointer on the period update
     # Usefull to just see, if PCM stream is stopped for a reason (usually wrong audio process timing from scheduler)
     # And to check the values from driver
     echo 11 > /proc/asound/card0/pcm0p/xrun_debug
    
     # Enable basic debugging and dump stack, check hardware pointer on all updates
     # Usefull to just see, if PCM stream is stopped for a reason (usually wrong audio process timing from scheduler)
     # And to do the exact check the values from driver
     echo 27 > /proc/asound/card0/pcm0p/xrun_debug
    
     # Enable basic debugging, do jiffies check and enable one shot dump of last 10 ring buffer positions
     # Usefull, when the position is broken only after some of time (to reduce ksyslog messages)
     echo 101 > /proc/asound/card0/pcm0p/xrun_debug
    
     # Enable basic debugging, do jiffies check and dump position on each period and hardware pointer update calls
     # Usefull when the lowlevel (specific) hardware driver is somehow broken
     echo 29 > /proc/asound/card0/pcm0p/xrun_debug
    

    不过我这里个人推荐使用:echo 53 > /proc/asound/xxx/pcm0p/xrun_debug

    关于proc asoc到更多描述,可以参考我这文章:Proc asound documentation

    常见原因分析

    根据经验,通常有几种原因出现XRUN:

    • Linux CFS(完全公平的调度程序)
    • 具有 SCHED_FIFO 调度的高优先级线程
    • 优先级倒置
    • 长时间调度延时
    • 长时间运行到中断处理 程序
    • 长时间中断禁用
    • 电源管理
    • 安全内核

    大部分情况下xrun都可以先试着调整period size和period count来解决,如果不起作用,还需要根据具体原因来具体分析。
    period_size:每次传输的数据长度。值越小,时延越小,cpu占用就越高。
    period_count:缓冲区period的个数。缓冲区越大,发生XRUN的机会就越少。

    默认情况下,在进入XRUN状态时会停止DMA传输,直到有available空间可写入(overrun时),或者直到有数据写入(underrun时)。
    但是用户空间可以通过配置silence_threshold来继续播放缓冲区的重复的音频数据或静音数据(silence_size为填充的大小),当空余空间超过silence threshold时,就hardware buffer 写入silence。
    PS:偶尔的系统繁忙导致的这种状态, 重复播放原有的音频数据会显得更平滑,效果更好。

    参考AOSP官网和ALSA官网:
    音频延迟的促成因素
    XRUN Debug

    展开全文
  • ALSA驱动框架

    在这里插入图片描述

    🚀返回专栏总目录

    沉淀、分享、成长,让自己和他人都能有所收获!😄

    📢高级 Linux 声音架构 (ALSA) 为 Linux 操作系统提供音频和 MIDI 功能。

    一、驱动框架


    ALSA驱动程序框架如下:

    • <

    展开全文
  • PCM 数据管理可以说是 ALSA 系统中最核心的部分。 不管是录音还是播放,都要用到buffer管理数据。 播放:copy_from_user 把用户态的音频数据拷贝到 buffer 中,启动 dma 设备把音频数据从 buffer 传送到 I2S tx ...
  • ALSA子系统(十六)------虚拟耳机驱动 Android音频子系统(四)------耳机拔插流程 那么必然少不了现在市场上较多的Type-C耳机。 常见的TYPE-C耳机有两种: 一种是通过TYPE-C转3.5mm的转接线接3.5mm耳机,这种...
  • 你好!这里是风筝的博客, 欢迎和我一起交流。 POP音基本原理 这个POP音的产生主要是因为codec开始工作时,耳机等输出或mic输入声道上的直流电平跳变产生的;手机或一般的手持设备上不会有负电压,音源信号必须在一...
  • 你好!这里是风筝的博客, 欢迎和我一起交流。 目前主流耳机分为美标耳机和欧标耳机,国内大部分厂商都使用欧标,所以也有把OMTP叫做国标。 其中,又有三段耳机和四段耳机之分,三段耳机时没有麦的,表作headphone...
  • 你好!这里是风筝的博客, 欢迎和我一起交流。 科大讯飞用到我司的一款芯片做识别笔,叫啥阿尔法蛋,一看就不是啥好蛋。。。。。...这客户反馈每次用识别笔去识别文字的时候,启动的时候概率性会卡住大概一秒钟的时间...
  • 移植tinyalsa工具参考上一篇文章:ALSA子系统(三)------Audio测试工具(tinyalsa) 如果是有 Android 环境,直接在external/tinyalsa目录下mm即可。 使用trace工具可以抓取tinyplay流程。 主要流程如下,附有注释,...
  • 这里我们有2个通道,依此类推: 1帧=(通道数)(以字节为单位的1个样本大小)=(2个通道)(每个样本2个字节(16位))= 4个字节(32位) 要维持2x 44.1 KHz模拟采样率,系统必须能够支持以Bytes / sec为单位的...
  • TinyAlsa是 Android 默认的 alsalib, 封装了内核 ALSA 的接口,用于简化用户空 间的 ALSA 编程。 合理的pcm_config可以做到更好的低时延和功耗,移动设备的开发优为敏感。 struct pcm_config { unsigned int ...
  • 一个android系统里面,当用户需要播放声音的时候,cpu把数据信号发送给声卡,在声卡内部进行数模转换(DAC),然后通过运放进行播放,其中line out输出原始数据,即还没有经过运放的数据。通过耳机运放称为headphone...
  • alsa-lib/test/pcm_mian.c文件里有个实例: /* pass the remaining samples, otherwise they're dropped in close */ err = snd_pcm_drain(handle); if (err ) printf("snd_pcm_drain failed: %s\n", snd_...
  • 音频子系统(ASOC框架)之Machine 音频子系统(ASOC框架)之Codec 但是有些场合,我们是不需要一个“真实”的codec做处理的,例如蓝牙通话,这时候只要一个虚拟声卡即可。这里提供一个虚拟声卡的驱动: /* * Driver for...
  • 你好!这里是风筝的博客, 欢迎和我一起交流。 hw parameter表示当前音频流使用的硬件参数,比如当前音频流使用的format,声道数,使用的哪个音频输出端口等等。 因为一个codec或者一个dai可以支持多种格式,比如一...
  • Plugin: hw 该插件直接与ALSA内核驱动程序通信。这是未经任何转换的原始通信。模仿mmap访问可以被启用,但是在这种情况下,预计会有更糟的延迟。 nonblock选项指定设备是否以非阻塞方式打开。请注意,此选项不会...
  • 你好!这里是风筝的博客, 欢迎和我一起交流。 所有的WAV都有一个文件头,这个文件头记录着音频流的...WAVE文件通常只是具有单个“ WAVE”块的RIFF文件,该“ WAVE”块由两个块组成-“ fmt”块指定数据格式,而

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 5,372
精华内容 2,148
关键字:

alsa子系统