现象：观看直播时出现图像卡顿或者声音断断续续？ 原因：在上下行网络带宽有1MB的前提下，主播推流端参数设置太高或者推流端的电脑或者手机配置太低导致推流端计算能力跟不上，导致时断时续。 解决方案：降低推流参数，特别是以下几个参数，不要超过建议值 参数 建议值(不高于) 分辨率 720p 帧速率 24fps x264预设值 Very fast 比特率 PPT桌面推流不高于1721kbps，摄像头现场推流不低于2000kbps，不高于2500kbps 音频质量 44.1KHz,128kbps 读取更多关于观看直播时出现图像卡顿或者声音断断续续时怎么办？ »

问题：成为分销商有无门槛？ 回答：零门槛(无需缴纳任何费用)。 问题：分销的流程是怎样的？ 回答：分销商赚钱的步骤如下 (第1步) https://heyubao.com/advertiser 点击一个悬赏广告； (第2步)点击【分销该直播/商品/店铺】； (第3步)复制系统自动生成的分销文案(含分销地址); (第4步).将复制好的文案发给微信好友/群/朋友圈（不做这个动作，不会有收入！合育宝广告系统只在微信生态内生效）； (第5步).只要有朋友点击就会有一笔分销收入，点击者也有一笔收入。 问题：这个收入是谁给的？ 回答：广告主！ 问题：广告主可以借助悬赏分销广告系统推广哪些项目？ 回答：一场直播活动及其预告/一个爆款商品/广告主的合育街店铺。 问题：广告主为什么愿意给钱？ 回答：花钱买您的流量！ 问题：这些流量有什么价值？ 回答：增加了推广项目的曝光量，扩大了潜在购买用户群，增长人气。 问题：我为什么要用私域流量赚钱？ 回答：让传播有价值！您的私域朋友需要您传播有价值的信息，私域传播给广告主、分销商、点击客都能带来价值！ 问题：合育宝提供广告平台和服务有什么收入？ 回答：分销商和点击客的收入中包含了10%的平台服务费（提现时自动扣除该项费用），这是合育宝广告系统的主要收入来源。 读取更多关于如何参与合育宝悬赏广告分销？ »

问题：微信零钱付款有什么要求？ 回答：微信公司有如下规定 (1).单笔付款额在【0.3-200】元之间，少于0.3元或者大于200元的付款请求都会失败； (2).每天最多支付10次，超过10次的提现付款请求都会失败，即每天最多提现2000元。 问题：作为广告分销商或者广告点击客，如果一天超过10笔收入后的钱怎么处理的？ 回答：超过10笔的后续收入不再自动提现，而是自动进入合育宝钱包，你可以在【我的资金】内按200元/次分批次人工提现，人工提现也是实时到账。 问题：怎样用微信充值？ 回答：目前提供下列三种微信充值方式 (1).在合育宝网站内充值，大致步骤如下：打开合育宝网站；登录进入【我的资金】，点击【充值】，选择充值金额，微信扫码完成付款；这种方式支持找人代付。 (2).在合育宝微信公众号内充值，大致步骤如下：关注合育宝微信公众号(下图)；点击【我的合育宝-我的钱包】，点击【充值】，选择充值金额，调起微信支付完成付款。 (3).在合育宝APP内充值，大致步骤如下：下载合育宝APP(安卓手机版)；打开合育宝APP；点击【我的】输入手机号码和密码完成登录；点击【我的】右上角【...】菜单，选择【我的资金】，点击【充值】，选择充值金额，调起微信APP完成付款。 读取更多关于微信付款问题汇总 »

问题：个人在合育宝的资金账户何时开通？ 回答：注册账号时自动开通？ 问题：合育宝资金来源有几项？ 回答：合育宝资金来源有下列几项 (1).本人充值入账； (2).主播的打赏收入； (3).卖货收入； (4).广告分销商收入（点击收入、提成收入）； (5).广告点击客收入（点击收入）； (6).付费直播（卖课收入）。 问题：合育宝资金支出有几项？ 回答：合育宝资金开支有下列几项 (1).本人提现出账（含0.6%微信支付佣金）； (2).买货支出（含5%平台佣金）； (4).广告主预算支出（含10%平台佣金）； (5).给主播的打赏费（含30%平台佣金）; (6).付费买课支出。 读取更多关于合育宝资金(钱包)问题汇总 »

在《如何开展您的第1次企业直播》帖子中【第4步：推流直播】有以下表述：进入"个人中心"，点击"显示推流地址二维码"，就可找到推流所需全部参数，用合育宝APP/腾讯视频云小程序/OBS即可推流；推流成功后，观众通过预告网址在各种设备上观看直播并留言互动。至此，恭喜您，您的企业已经成功迈出了数字化转型的第一步。本文通过图文方式重点讲解如何用合育宝APP推流，确保任何人都能像用相机一样轻松做企业直播。 图1：打开合育宝APP 图2：登录/注册 图3：输入手机号码和密码登录，如果手机号未注册，则自动切换成注册 图4：确保直播应用选中了【RTMP直播及录播】选项 图5：确保直播V课有效，如果是【无】，则点击【创建V课活动】 图6：按照上图所示表格要求，创建一个V课活动 图7：创建完V课之后，可以修改和补充更多有关V课的信息 图8-1：新建直播活动(简称V课)进入预告列表 图8-2：点击直播预告详情页右上角【分享】直播预告 图8-3：直播预告分享图文海报，点击左下角分享图标 图8-4：将直播预告图片分享给微信好友/微信群和朋友圈 图9：点击图2顶端【推流】图标，进入本直播推流预览页面，上图是竖屏直播 图10：强烈推荐采用横屏直播，即按下上述红色推流按钮前，先把手机横屏 图11：按下推流按钮后，系统弹出上述对话提示框，【确定】正式推流，【取消】更改V课 图12：正式推流画面，点击【方形红色按钮】停止推流，点击【暂停按钮】暂停推流 图13：直播结束后，可以立即回看 图14：点击【我的】页面右上角的三点图标 图15：点击【我的V课】 图16：点击【我的V课视频】 图17：对直播视频进行【剪去头部段、剪去中间段、剪去尾部段、逆时针旋转90度，顺时针旋转90度】五类剪辑操作 图18：删除不用的直播回看视频 图19：删除不用的V课活动 图20：直播数据分析列表 图21：直播观众分析 图22：另一个删除直播活动的入口(跟图19操作等效) 图23：确认删除 至此，无论您是直播小白还是直播专家，都已完成在合育宝平台的一次完成的企业直播工作，可恭可贺。 读取更多关于用合育宝APP推流直播图文教程 »

企业运营模式向线上转移，企业直播成为必要部署由于企业直播用户数量全面攀升，据公开资料统计，2020年2月，企业直播在用户端完成高位迭代，相比1月，用户数实现约7倍的增长。上亿的用户群体对企业直播尝试，且用户留存率大于90%。2020年第一季度，企业直播用户数量持续走高，月度最高约3.4亿人。企业运营模式整体向线上转移，企业直播已然成为企业发展核心竞争力。因企业直播的营销效果与在线用户的活跃量最直接影响。加大企业直播用户引流成为企业线上运营关键。 第1步：免费注册直播账号 点击免费注册合育宝会员，输入手机号码、登录密码和短信验证码之后即可注册成功。 第2步：免费创建V课 登录成功后，进入"个人中心-我的直播"，添加一个V课。 第3步：分享直播预告 点击"个人中心-我的直播-我的V课"，打开直播预告，将预告网址分享到微信好友/微信群/朋友圈，朋友点击该网址即可通过关注您或者输入手机号码就能完成该直播的预约，开播前15分钟预约用户能够收到短信或者微信提醒。 第4步：推流直播 进入"个人中心"，点击"显示推流地址二维码"，就可找到推流所需全部参数，用合育宝APP/腾讯视频云小程序/OBS即可推流；推流成功后，观众通过预告网址在各种设备上观看直播并留言互动。至此，恭喜您，您的企业已经成功迈出了数字化转型的第一步。如何用合育宝APP推流，详见《用合育宝APP推流直播图文教程》。 合育宝直播跟抖音、快手、视频号、微视有何不同？ 第一，合育宝直播为学校/教育局以及不希望将视频数据托管在第三方平台的机构提供系统自建服务，将直播以及点播流媒体服务所需的软硬件系统交付到用户自备服务器上； 第二、合育宝直播支持回看，适合直播结束后持续观看； 第三、合育宝直播时间不限，直播10小时也没有问题，回看也是； 第四，合育宝直播支持【直播免费,回看收费】或者【直播收费,回看免费】等各种知识付费； 第五，合育宝直播适合在微信朋友圈和微信群以及微信好友内分享H5直播链接，观众门槛低，容易触达，适合商业直播； 第六，合育宝直播提供"观众、留言、打赏、预约、新客"5类观众数据分析，提供"短信联系、互加好友、店铺留言"等多种互动手段，让每一场直播都有价值。 读取更多关于如何开展您的第1次企业直播? »

随着直播行业的发展，企业直播的数量及频率也随之上升。 企业为什么要做企业直播？今天一次性回答你企业为什么需要直播营销？ 1.都说移动互联网的时代就是直播的时代，这句话对吗？ 随着智能手机的普及，4G业务发展成熟，移动互联网的发展，手机上网用户激增，手机终端成为首要上网工具。直播符合移动互联网的大趋势，直播表现形式丰富，真实性、互动性、实时性强，能够带来更好的娱乐属性以及信息属性，符合移动互联网场景化、碎片化、个性化、去中心化的特点和趋势。所以说，移动互联网的时代就是直播的时代并无为过。 2.直播比传统媒体好在哪里？ 随着互联网的兴起，传统媒体逐渐衰落，各种向外宣传途径的增多，无论是企业或是个人都意识到，只靠基础图文的日常传播已经满足不了粉丝日益增长的优质内容需求。越来越多的企业利用直播营销去实现与用户的实时互动。这相较于传统电视，直播的一大优势就是能够满足用户更为多元的需求。 当观众在观看屏幕内容的时候。不仅仅是单向的观看，还能通过直播，更直观的知晓商品的各种属性，甚至可以挑起关注性高的话题讨论，这种互动的真实性和立体性，也只有在直播才能展现。 3.企业直播与娱乐直播有什么区别？ 企业直播是专注于企业级的直播平台，适合企业或商家做直播营销或宣传活动，而娱乐直播则比较适合主播做一些游戏、才艺类等类型的娱乐性直播。还有活跃于娱乐直播平台的用户，都是抱着娱乐休闲的心态看直播的，很少有购买的意向，当他们看到广告时，很有可能立马退出，寻找新的娱乐直播节目，这些流量对企业或商家来说用处不大。 4.传统行业可以做企业直播吗？ 当然，公司一般有对外和对内两种活动，对外可以用直播来做营销宣传，成本低、速度快、效果好，轻松达到成交获客的目标；对内用来做培训或会议等活动，可以记录回放，降低运营成本。很多知名传统公司也在借助直播跟上市场的潮流。 5.做一场企业直播麻烦吗？ 并不，企业直播技术日益成熟，专业的直播技术人员可以在短时间将设备及线路调整完备，相比于其他类型直播也并不麻烦。 6.传统行业可以做企业直播吗？ 随着技术的成熟和移动互联的发展，未来的企业，都需要建立一个视频直播，使直播与企业宣传营销完美结合，帮自己吸引粉丝，吸引客户，转化成交。 企业直播可以将整个企业的文化通过视频的模式直接表达给目标用户，通过大数据、用户画像等技术，可以优化企业品牌宣传的战略，意义可想而知。 原文：https://www.sohu.com/a/479166198_120775766 读取更多关于为什么要做企业直播？企业直播有什么意义？ »

现象：在公司的203.*.*.40服务器上Ping heyubao.com 出现 unknown host，但是ping baidu.com正常。 原因：/etc/resolv.conf 中的 nameserver 设置不对。 解决方案：vi /etc/resolv.conf ，修改dns服务器ip地址即可。 读取更多关于Ping heyubao.com unknown host »

Cross Origin Resource Sharing (CORS) is a mechanism that is used by browsers, primarily to validate permissions for access to content from a different origin. What is CORS? When a browser loads a web page, it enforces the Same-origin Policy, which means that it only allows content to be fetched from the same origin as the web page. However, in some cases, a web page might need access to assets from multiple origins that trust that website. This is where CORS comes in. This security mechanism exists only if an application has or is an HTTP client, and if that application implements CORS. Nearly all modern browsers, such as Chrome, Firefox, and Safari, implement CORS. To clarify, an origin with respect to CORS does not have to be the same as a CDN origin. An origin in CORS is defined by a URI scheme, domain, and any possible port number. For example, https://www.example.com:1443 is a different origin than http://www.example.com. And so, a CDN can also be considered as a CORS origin from a browser's perspective. How CORS works CORS can handle two types of requests: simple requests and preflighted requests, which are more complex. Simple requests First request (resource access): Simple requests through CORS are either GET or POST requests from the web page of one origin that's attempting to gain access to the URL of another origin for resources. When making such a request, the browser automatically sets CORS request headers. Primarily, it sets the origin of the web page making the request in the Origin HTTP header, automatically. The CORS request also can contain a set of certain, standard HTTP headers , while maintaining its status as a simple CORS request, from the browser's perspective. The server that receives the CORS request processes the request, and might send a set of CORS response headers back to the browser, with the requested content. These CORS response headers contain values specifying whether the current web page is allowed access to those resources, whether the headers sent are acceptable for that request, and so forth. If the browser is unable to see its CORS request satisfied by the CORS response headers, it automatically prevents the access to and loading of the content. Otherwise, it sees that the CORS origin is giving permission to use the resource, and it allows the access to and loading of the requested content. Preflighted requests First request (preflight): Second request (resource access): For more complex CORS communication between the browser and a CORS origin that's different than the requesting web page, a preflight request is required before an actual resource access. Certain situations might require preflighting CORS requests, such as HTTP methods that are not GET or POST methods, or using non-standard HTTP headers with the request - even if it is a GET or POST request, and so forth. If a preflight request is needed, here's how the events unfold: The browser sends a request using the HTTP OPTIONS method to the server with all of the intended CORS request headers. The server processes those CORS request headers, and can respond with CORS response headers containing no actual content data. The browser checks those CORS response headers to make sure that the CORS request is allowed. If the browser sees that the intended resource request should be allowed by the server, it makes a second request to the browser with the intended HTTP method, whether GET, POST, PUT and so on, with the same CORS request headers. Afterward, the communication between the browser and CORS origin (different than that of the web page) proceeds as if it was a simple CORS request. Similar to a simple CORS request, content and resources are accessible and can be loaded if this second CORS request is allowed. Setting up CORS at your origin As shown in the previous diagrams, CORS is initiated by the requesting HTTP client. However, the effects depend on the requested origin. For your content to be ready for CORS requests, your origin must be configured correctly to respond with the correct CORS response headers and the correct access permissions. The following example shows a basic CORS configuration for a Nginx server: http { # some http context configs server { # some server context configs # URI path to some content location /my-static-content { # some location context configs # Handle simple requests # # Consider only "HTTP GET" requests (content fetching) if ($request_method = 'GET') { # Allows the browser to access data from this server during CORS, # only if the request comes from a web page from the following origin add_header 'Access-Control-Allow-Origin' 'https://www.example.com'; } # Handle preflight requests if ($request_method = 'OPTIONS') { # Allows the browser to access data from this server during CORS, # only if the request comes from a web page from the following origin add_header 'Access-Control-Allow-Origin' 'https://www.example.com'; # Allows only GET requests add_header 'Access-Control-Allow-Methods' 'GET'; # Allows the following headers in the browser's request headers # that may have been added by anything other than what the browser had added automatically add_header 'Access-Control-Allow-Headers' 'pragma'; # Specifies to the browser how long it should cache this preflight response add_header 'Access-Control-Max-Age' 1728000; # HTTP 204 response code means success, # but also that it should expect no content from this (preflight) response return 204; } # more location context configs # If it is not a complex CORS situation requiring a preflight response, # then finally attempt to serve the file whose path falls under this location block's URI path match # # If no such file is found, then present an HTTP 404 code (not found) try_files $uri =404; } # more server context configs } # more http context configs } Generally, the browser should freely load content when it sees a Access-Control-Allow-Origin: * in the server's CORS response headers according to the w3 specification regarding that wildcard value . However, not all browsers support Access-Control-Allow-Origin: *. If the server must support access from multiple web pages, each served from a different origin, a single origin value for Access-Control-Allow-Origin should be dynamically generated per request. The following is a basic example of such a use case for an Nginx server: http { # some http context config ###### # Input from $http_origin, the value in Origin HTTP header # Output to $cors_allowed_origin, a string # # Full string match on the Origin header value # # Attempt to find a match for the value from $http_origin using regex on the left column. # If a match is found, then evaluate $cors_allowed_origin to the same value as $http_origin # Else, default evaluate $cors_allowed_origin to an empty string, so browsers will disallow the CORS request ###### map $http_origin $cors_allowed_origin { default ''; ~^http(s)?://(www|www2|cdn|dev)\.example\.com$ $http_origin; } server { # some server context configs # URI path to some content location /my-static-content { # some location context configs # Handle simple requests if ($request_method = 'GET') { add_header 'Access-Control-Allow-Origin' $cors_allowed_origin; } # Handle preflight requests if ($request_method = 'OPTIONS') { add_header 'Access-Control-Allow-Origin' '$cors_allowed_origin; add_header 'Access-Control-Allow-Methods' 'GET'; add_header 'Access-Control-Allow-Headers' 'pragma'; add_header 'Access-Control-Max-Age' 1728000; return 204; } # more location context configs try_files $uri =404; } # more server context configs } # more http context configs } The previous example uses the map directive to avoid overusing the if Nginx statement. Now, when a CORS request is made to this server and matches that URI path, the server responds with the Access-Control-Allow-Origin header containing the value http://www.example.com, https://cdn.example.com, or http://dev.example.com, when the content is requested from http://www.example.com, https://cdn.example.com, http://dev.example.com, and so forth. Setting up CORS for CDN CDN is largely transparent to the CORS setup of the origin so it does not require a specific CDN configuration. If the CDN Edge server cannot find a cached response for the first request for some content, it forwards the request to the origin host. If the origin host is set up to handle CORS requests, and this request has the Origin header, then it should respond back to the Edge with a CORS header of Access-Control-Allow-Origin and the associated value. The overall response, including that header and value, is cached in the CDN. Any subsequent request for the object at the same URI path is served from the cache and includes the Access-Control-Allow-Origin header value that was originally received from the origin. Multiple CORS origin support In some cases, you can allow a list of specific origins (not all) to access your CDN contents, and need CDN to serve different Access-Control-Allow-Origin response headers for different origins (not wildcard * for any origins). However, CDN caches the headers along with contents, so it might serve the cached Access-Control-Allow-Origin header to the request, which might not match. You can leverage the Cache Key query optimization to add different parameters in the URLs for different origins. This way, the content and headers are cached differently. For example, suppose you've set the CDN cdn.example.com to serve contents for the two origins (abc.com and 123.com), and want to add different parameters for each origin; for example, https://cdn.example.com/test.json?domain=abc.com and https://cdn.example.com/test.json?domain=123.com. CDN would return different Access-Control-Allow-Origin headers that are served by your back-end server: Request from abc.com origin returns access-control-allow-origin: https://abc.com: # curl -H "Origin: https://abc.com" -H "Referer: https://abc.com/" -i https://cdn.example.com/test.json?domain=abc.com HTTP/2 200 access-control-allow-origin: https://abc.com access-control-allow-methods: GET access-control-allow-credentials: true ... Request from 123.com origin returns access-control-allow-origin: https://123.com: # curl -H "Origin: https://123.com" -H "Referer: https://123.com/" -i https://cdn.example.com/test.json?domain=123.com HTTP/2 200 access-control-allow-origin: https://123.com access-control-allow-methods: GET access-control-allow-credentials: true ... Troubleshooting CORS and CORS requests If your origin server is set up for CORS, and you do not see the Access-Control-Allow-Origin header that is returned to the browser’s request, it is possible that the response header cached in CDN was for a request that didn't have the origin header in the request. CDN caches response headers from the origin host. However, the cached headers are based on the request that triggered the request to origin. In that case, the response headers might not include the CORS headers. Clear the cache in CDN for that path using CDN’s purge functionality, and retry the request from the client. The Vary response header from your origin server can also cause unexpected behavior when fetching content through your CDN. Other than one specific exception, the CDN does not cache content (and its associated response header) from your origin server, if the server responds with a Vary header. Currently, our service removes the Vary header from the origin to render the object cacheable, if the object is one of the following file types: aif, aiff, au, avi, bin, bmp, cab, carb, cct, cdf, class, css, doc, dcr, dtd, exe, flv, gcf, gff, gif, grv, hdml, hqx, ico, ini, jpeg, jpg, js, mov, mp3, nc, pct, pdf, png, ppc, pws, swa, swf, txt, vbs, w32, wav, wbmp, wml, wmlc, wmls, wmlsc, xsd, zip, webp, jxr, hdp, wdp, pict, tif, tiff, mid, midi, ttf, eot, woff, otf, svg, svgz, jar, woff2, json. If the object to cache is not one of these file types, remove the Vary header from the origin server's response for that object and try again after using CDN's Purge functions. location /delete*****file/ { # Handle simple requests # # Consider only "HTTP DELETE" requests (content delete) if ($request_method = 'DELETE') { # Allows the browser to access data from this server during CORS, # only if the request comes from a web page from the following origin add_header 'Access-Control-Allow-Origin' 'https://heyubao.com'; } # Handle preflight requests if ($request_method = 'OPTIONS') { # Allows the browser to access data from this server during CORS, # only if the request comes from a web page from the following origin add_header 'Access-Control-Allow-Origin' 'https://heyubao.com'; # Allows only DELETE requests add_header 'Access-Control-Allow-Methods' 'DELETE'; # Allows the following headers in the browser's request headers # that may have been added by anything other than what the browser had added automatically add_header 'Access-Control-Allow-Headers' 'pragma'; # Specifies to the browser how long it should cache this preflight response add_header 'Access-Control-Max-Age' 1728000; # HTTP 204 response code means success, # but also that it should expect no content from this (preflight) response return 204; } # more location context configs # If it is not a complex CORS situation requiring a preflight response, # then finally attempt to serve the file whose path falls under this location block's URI path match # # If no such file is found, then present an HTTP 404 code (not found) try_files $uri =404; alias /usr/local/*****/html/vod/; dav_access user:rw group:rw all:rw; dav_methods DELETE; min_delete_depth 1; } 读取更多关于Nginx CORS 跨域解决方案 »

回音消除Google 开发文档原文： /** * Acoustic Echo Canceler (AEC). * <p>Acoustic Echo Canceler (AEC) is an audio pre-processor which removes the contribution of the * signal received from the remote party from the captured audio signal. * <p>AEC is used by voice communication applications (voice chat, video conferencing, SIP calls) * where the presence of echo with significant delay in the signal received from the remote party * is highly disturbing. AEC is often used in conjunction with noise suppression (NS). * <p>An application creates an AcousticEchoCanceler object to instantiate and control an AEC * engine in the audio capture path. * <p>To attach the AcousticEchoCanceler to a particular {@link android.media.AudioRecord}, * specify the audio session ID of this AudioRecord when creating the AcousticEchoCanceler. * The audio session is retrieved by calling * {@link android.media.AudioRecord#getAudioSessionId()} on the AudioRecord instance. * <p>On some devices, an AEC can be inserted by default in the capture path by the platform * according to the {@link android.media.MediaRecorder.AudioSource} used. The application should * call AcousticEchoCanceler.getEnable() after creating the AEC to check the default AEC activation * state on a particular AudioRecord session. * <p>See {@link android.media.audiofx.AudioEffect} class for more details on * controlling audio effects. */ 场景就是在手机播放声音和声音录制同时进行，但是手机播放的声音不会被本机录制，达到了消除的效果。微信对讲的最适合不过了，但是微信的回音消除好像是不是自己弄的。 文档大致意思：创建android.media.AudioRecord 对象的时候，可以通过这个对象获取到一个audio session 的ID，获取方法getAudioSessionId()，这个ID在创建AcousticEchoCanceler的时候要用到（创建对象：AcousticEchoCanceler.create(audioSessionId)），最后播放音频时（这里是用AudioTrack播放）传入这个ID就行了。 1.首先创建AudioRecord对象，里面的参数可以自己查资料知道什么是采样率，声道，位数。 private AudioRecord mRecorder; private byte[] pcm; private int mRecorderBufferSize; /** * 初始化录音 */ public void initRecorder() { mRecorderBufferSize = AudioRecord.getMinBufferSize(8000, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT); pcm = new byte[320]; mRecorder = new AudioRecord(MediaRecorder.AudioSource.VOICE_COMMUNICATION, 8000, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT, mRecorderBufferSize); } 2.其次，初始化AudioTrack（注意下传入的audioSessionId） private AudioRecord mRecorder; private byte[] pcm; private int mRecorderBufferSize; /** * 初始化录音 */ public void initRecorder() { mRecorderBufferSize = AudioRecord.getMinBufferSize(8000, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT); pcm = new byte[320]; mRecorder = new AudioRecord(MediaRecorder.AudioSource.VOICE_COMMUNICATION, 8000, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT, mRecorderBufferSize); } 3.最后创建AcousticEchoCanceler private AcousticEchoCanceler acousticEchoCanceler; private void initAEC() { if (AcousticEchoCanceler.isAvailable()) { if (acousticEchoCanceler == null) { acousticEchoCanceler = AcousticEchoCanceler.create(audioSessionId); Log.d(TAG, "initAEC: ---->" + acousticEchoCanceler + "\t" + audioSessionId); if (acousticEchoCanceler == null) { Log.e(TAG, "initAEC: ----->AcousticEchoCanceler create fail."); } else { acousticEchoCanceler.setEnabled(true); } } } } 4.最后播放就可以了（OK） public void write(byte[] data) { if (mAudioTrack != null && mAudioTrack.getPlayState() == AudioTrack.PLAYSTATE_PLAYING) { mAudioTrack.write(data, 0, data.length); } } 读取更多关于Android 回音消除(AcousticEchoCanceler)的使用 »