27 মার্চ, 2025 থেকে, আমরা AOSP তৈরি করতে এবং অবদান রাখতে aosp-main এর পরিবর্তে android-latest-release ব্যবহার করার পরামর্শ দিচ্ছি। আরও তথ্যের জন্য, AOSP-তে পরিবর্তনগুলি দেখুন।
সেভ করা পৃষ্ঠা গুছিয়ে রাখতে 'সংগ্রহ' ব্যবহার করুন
আপনার পছন্দ অনুযায়ী কন্টেন্ট সেভ করুন ও সঠিক বিভাগে রাখুন।
সাউন্ড ট্রিগার বৈশিষ্ট্যটি অ্যাপগুলিকে নির্দিষ্ট অ্যাকোস্টিক ইভেন্টগুলি যেমন হটওয়ার্ডের মতো কম শক্তি এবং গোপনীয়তা-সংবেদনশীল পদ্ধতিতে শোনার ক্ষমতা প্রদান করে৷ সাউন্ড ট্রিগার ব্যবহারের উদাহরণ হল অ্যাসিস্ট্যান্ট এবং নাউ প্লে হচ্ছে।
এই পৃষ্ঠাটি সাউন্ড ট্রিগার আর্কিটেকচার এবং এর HAL (হার্ডওয়্যার অ্যাবস্ট্রাকশন লেয়ার) ইন্টারফেসের একটি ওভারভিউ দেয়।
সাউন্ড ট্রিগার স্ট্যাক
সাউন্ড ট্রিগার সাবসিস্টেমটি লেয়ারে তৈরি করা হয়েছে যেমন চিত্র 1 এ দেখানো হয়েছে:
চিত্র 1: সাউন্ড ট্রিগার স্ট্যাক
নিম্নলিখিত তালিকাটি চিত্র 1-এ দেখানো প্রতিটি স্তরকে আরও বিশদে বর্ণনা করে:
HAL স্তরে (সবুজ রঙে) বিক্রেতা নির্দিষ্ট কোড থাকে যা সাউন্ড ট্রিগার HAL (STHAL) ইন্টারফেস প্রয়োগ করে।
SoundTriggerMiddleware (হলুদে) HAL ইন্টারফেসের উপরে থাকে। এটি HAL এর সাথে যোগাযোগ করে এবং বিভিন্ন ক্লায়েন্টের মধ্যে HAL ভাগ করে নেওয়া, লগিং করা, অনুমতি প্রয়োগ করা এবং পুরানো HAL সংস্করণগুলির সাথে সামঞ্জস্যতা পরিচালনা করার মতো কার্যকারিতার জন্য দায়ী।
SoundTriggerService (নীল ভাষায়) সিস্টেম মিডলওয়্যারের উপরে থাকে। এটি টেলিফোনি এবং ব্যাটারি ইভেন্টগুলির মতো অন্যান্য সিস্টেম বৈশিষ্ট্যগুলির সাথে একীকরণের সুবিধা দেয়৷ এটি সাউন্ড মডেলগুলির একটি ডাটাবেসও বজায় রাখে, অনন্য আইডি দ্বারা সূচীকৃত।
SoundTriggerService স্তরের উপরে, স্ট্যাক (বাদামী রঙে) অ্যাসিস্ট্যান্ট এবং জেনেরিক অ্যাপের জন্য নির্দিষ্ট বৈশিষ্ট্যগুলিকে আলাদাভাবে পরিচালনা করে।
সাউন্ড ট্রিগার স্ট্যাকের কাজ হল বিচ্ছিন্ন ইভেন্টগুলি প্রদান করা যা অ্যাকোস্টিক, ট্রিগার ইভেন্টগুলিকে প্রতিনিধিত্ব করে। বেশিরভাগ ক্ষেত্রে, সাউন্ড ট্রিগার স্ট্যাক অডিওর সাথে ডিল করে না। ট্রিগার ইভেন্টগুলি প্রাপ্তির পরে, অ্যাপগুলি অডিও ফ্রেমওয়ার্কের মাধ্যমে একটি AudioRecord অবজেক্ট খোলার মাধ্যমে ইভেন্টগুলির সময়কে ঘিরে প্রকৃত অডিও স্ট্রিমে অ্যাক্সেস পায়। সাউন্ড ট্রিগার HAL API গুলি ট্রিগার করা ইভেন্টের সাথে একটি হ্যান্ডেল প্রদান করে যা অডিও ফ্রেমওয়ার্কের সাথে ব্যবহার করা হয়। সুতরাং, যেহেতু সাউন্ড ট্রিগার HAL এবং অডিও HAL হুডের নীচে সংযুক্ত, তারা সাধারণত একটি প্রক্রিয়া ভাগ করে।
সাউন্ড ট্রিগার HAL ইন্টারফেস
সাউন্ড ট্রিগার HAL (STHAL) ইন্টারফেস হল সাউন্ড ট্রিগার স্ট্যাকের বিক্রেতার নির্দিষ্ট অংশ এবং এটি হটওয়ার্ড এবং অন্যান্য শব্দের হার্ডওয়্যার স্বীকৃতি পরিচালনা করে। STHAL একটি নির্দিষ্ট শ্রেণীর শব্দ শনাক্ত করার জন্য ডিজাইন করা একটি ভিন্ন অ্যালগরিদম চালানোর সাথে এক বা একাধিক ইঞ্জিন সরবরাহ করে। যখন STHAL একটি ট্রিগার সনাক্ত করে, এটি একটি ইভেন্টকে ফ্রেমওয়ার্কে পাঠায় এবং তারপর সনাক্তকরণ বন্ধ করে দেয়।
STHAL ইন্টারফেসটি /hardware/interfaces/soundtrigger/ অধীনে নির্দিষ্ট করা হয়েছে।
ISoundTriggerHw ইন্টারফেস একটি নির্দিষ্ট সময়ে চলমান এক বা একাধিক সনাক্তকরণ সেশন এবং শাব্দ ঘটনা শোনার ক্ষমতা সমর্থন করে। ISoundTriggerHw.getProperties() এ একটি কল বাস্তবায়নের বিবরণ এবং ক্ষমতা সম্বলিত একটি Properties কাঠামো প্রদান করে।
একটি অধিবেশন সেট আপ করার প্রাথমিক প্রবাহ চিত্র 2 এ নিম্নরূপ ব্যাখ্যা করা হয়েছে:
চিত্র 2: STHAL স্টেট ডায়াগ্রাম
নিম্নলিখিত পদক্ষেপগুলি প্রতিটি রাজ্যকে আরও বিশদে বর্ণনা করে:
HAL ক্লায়েন্ট loadSoundModel() বা loadPhraseSoundModel() ব্যবহার করে একটি মডেল লোড করে। প্রদত্ত মডেল অবজেক্ট নির্দেশ করে যে কোন বাস্তবায়ন-নির্দিষ্ট সনাক্তকরণ অ্যালগরিদম (ইঞ্জিন) ব্যবহার করতে হবে, সেইসাথে এই অ্যালগরিদমের জন্য প্রযোজ্য পরামিতিগুলি। সাফল্যের পরে, এই পদ্ধতিগুলি একটি হ্যান্ডেল ফেরত দেয় যা পরবর্তী কলগুলিতে এই মডেলটিকে উল্লেখ করতে ব্যবহৃত হয়।
মডেলটি সফলভাবে লোড হয়ে গেলে, HAL ক্লায়েন্ট সনাক্তকরণ শুরু করতে startRecognition() কল করে। নিম্নলিখিত ইভেন্টগুলির মধ্যে একটি না হওয়া পর্যন্ত স্বীকৃতি পটভূমিতে চলতে থাকে:
এই মডেলটিতে একটি stopRecognition() বলা হয়েছে।
একটি সনাক্তকরণ ঘটেছে.
সম্পদের সীমাবদ্ধতার কারণে সনাক্তকরণ স্থগিত করা হয়েছে, উদাহরণস্বরূপ, যখন একটি উচ্চতর অগ্রাধিকার ব্যবহারের ক্ষেত্রে শুরু করা হয়েছে।
পরবর্তী দুটি ক্ষেত্রে, কলব্যাক ইন্টারফেসের মাধ্যমে একটি স্বীকৃতি ইভেন্ট পাঠানো হয় যা লোড করার পরে HAL ক্লায়েন্ট দ্বারা নিবন্ধিত হয়। সমস্ত ক্ষেত্রে, এই ঘটনাগুলির যে কোনও একটি ঘটলে, সনাক্তকরণ নিষ্ক্রিয় হয়ে যায় এবং আর কোনও স্বীকৃতি কলব্যাক অনুমোদিত হয় না৷
একই মডেল পরবর্তী সময়ে আবার শুরু করা যেতে পারে, এবং এই প্রক্রিয়াটি যতবার প্রয়োজন ততবার পুনরাবৃত্তি করা যেতে পারে।
অবশেষে, একটি নিষ্ক্রিয় মডেল যেটির আর প্রয়োজন নেই HAL ক্লায়েন্ট দ্বারা unloadModel() এর মাধ্যমে আনলোড করা হয়।
HAL ত্রুটিগুলি পরিচালনা করুন
ড্রাইভার বাস্তবায়নের মধ্যে নির্ভরযোগ্য এবং সামঞ্জস্যপূর্ণ আচরণ নিশ্চিত করার জন্য, Android 11-এ, HAL থেকে ফিরে আসা যেকোন অ-সফল ত্রুটি কোডগুলিকে প্রোগ্রামিং ত্রুটি হিসাবে গণ্য করা হয়, যেখান থেকে পুনরুদ্ধারের জন্য HAL প্রক্রিয়া পুনরায় চালু করা প্রয়োজন। এটি একটি শেষ অবলম্বন পুনরুদ্ধারের কৌশল এবং প্রত্যাশা হল যে এই ধরনের ঘটনাগুলি সঠিকভাবে কাজ করা সিস্টেমে ঘটবে না।
এই পৃষ্ঠার কন্টেন্ট ও কোডের নমুনাগুলি Content License-এ বর্ণিত লাইসেন্সের অধীনস্থ। Java এবং OpenJDK হল Oracle এবং/অথবা তার অ্যাফিলিয়েট সংস্থার রেজিস্টার্ড ট্রেডমার্ক।
2025-07-29 UTC-তে শেষবার আপডেট করা হয়েছে।
[[["সহজে বোঝা যায়","easyToUnderstand","thumb-up"],["আমার সমস্যার সমাধান হয়েছে","solvedMyProblem","thumb-up"],["অন্যান্য","otherUp","thumb-up"]],[["এতে আমার প্রয়োজনীয় তথ্য নেই","missingTheInformationINeed","thumb-down"],["খুব জটিল / অনেক ধাপ","tooComplicatedTooManySteps","thumb-down"],["পুরনো","outOfDate","thumb-down"],["অনুবাদ সংক্রান্ত সমস্যা","translationIssue","thumb-down"],["নমুনা / কোড সংক্রান্ত সমস্যা","samplesCodeIssue","thumb-down"],["অন্যান্য","otherDown","thumb-down"]],["2025-07-29 UTC-তে শেষবার আপডেট করা হয়েছে।"],[],[],null,["# Sound Trigger\n\nThe Sound Trigger feature provides apps with the ability to listen for certain\nacoustic events, like hotwords, in a low-power and privacy-sensitive manner.\nExample use cases of Sound Trigger are Assistant and Now Playing.\n\nThis page gives an overview of the Sound Trigger architecture and its HAL\n(Hardware Abstraction Layer) interface.\n\nSound Trigger stack\n-------------------\n\nThe Sound Trigger subsystem is built in layers as shown in Figure 1:\n\n**Figure 1:** Sound Trigger stack\n\nThe following list describes each layer shown in Figure 1 in more detail:\n\n- The **HAL layer** (in green) contains the vendor specific code which\n implements the [Sound Trigger HAL](#sthal-interface) (STHAL) interface.\n\n | **Note:** A direct implementation of the STHAL interface is recommended rather than as an adapter around an implementation of a legacy HAL.\n- The **`SoundTriggerMiddleware`** (in yellow) resides above the HAL\n interface. It communicates with the HAL and is responsible for functionalities\n such as sharing the HAL between different clients, logging, enforcing\n permissions and handling compatibility with older HAL versions.\n\n- The **`SoundTriggerService`** (in blue) system resides above the middleware.\n It facilitates integration with other system features, such as telephony and\n battery events. It also maintains a database of sound models, indexed by unique\n IDs.\n\n- Above the `SoundTriggerService` layer, the stack (in brown) handles features\n specific to Assistant and generic apps separately.\n\nThe function of the Sound Trigger stack is to deliver discrete events that\nrepresent acoustic, trigger events. In most cases, the Sound Trigger stack does\nnot deal with audio. Upon receipt of the trigger events, apps get access to the\nactual audio stream, surrounding the time of the events, by opening an\n`AudioRecord` object via the Audio framework. The Sound Trigger HAL APIs provide\na handle with the triggered event that is used with the Audio Framework. Hence,\nsince the Sound Trigger HAL and Audio HAL are connected under the hood, they\ntypically share a process.\n| **Note:** Since models and data types are opaque to the framework in the Sound Trigger subsystem, it is expected that apps and the HAL implementation maintain a \"hidden contract\", that is, the actual contents, format and semantics of those data types are agreed upon. Hence, apps using Sound Trigger are intended to be vendor provided rather than by independent developers.\n\nSound Trigger HAL interface\n---------------------------\n\nThe Sound Trigger HAL (STHAL) interface is the vendor specific part of the Sound\nTrigger stack and it handles hardware recognition of hotwords and other sounds.\nSTHAL provides one or more engines with each one running a different algorithm\ndesigned to detect a specific class of sounds. When STHAL detects a trigger, it\nsends an event to the framework and then stops the detection.\n\nThe STHAL interface is specified under `/hardware/interfaces/soundtrigger/`.\n\nThe `ISoundTriggerHw` interface supports the ability to have one or more\ndetection sessions running at a given time and to listen to acoustic events.\nA call to `ISoundTriggerHw.getProperties()` returns a `Properties` structure\ncontaining implementation description and capabilities.\n\nThe basic flow of setting up a session is explained as follows in Figure 2:\n\n**Figure 2:** STHAL state diagram\n\nThe following steps describe each state in more detail:\n\n1. The HAL client loads a model using `loadSoundModel()` or\n `loadPhraseSoundModel()`. The provided model object indicates which\n implementation-specific detection algorithm (engine) to use, as well as the\n parameters applicable for this algorithm. Upon success, these methods return a\n handle which is used to reference this model in subsequent calls.\n\n2. Once the model has been successfully loaded, the HAL client calls\n `startRecognition()` to begin detection. Recognition continues to run in the\n background until one of the following events occurs:\n\n 1. A `stopRecognition()` has been called on this model.\n 2. A detection has occurred.\n 3. Detection is aborted due to resource constraints, for example, when a higher priority use case has been initiated.\n\n In the latter two cases, a recognition event is sent via the callback\n interface that is registered by the HAL client upon loading. In all cases,\n after any of these events occur, the detection becomes inactive and no more\n recognition callbacks are allowed.\n\n The same model can be started again at a later time, and this process can be\n repeated as many times as needed.\n3. Finally, an inactive model that is no longer needed is unloaded by the HAL\n client via `unloadModel()`.\n\n| **Note:** When a model is started, the HAL client can call `forceRecognitionEvent()` to generate a forced recognition event. The returned event is similar to a normal recognition event, but has its status field set to `FORCED`. Such recognition events do not automatically stop the recognition. Instead, the model state remains running even after the event has been delivered.\n\nHandle HAL errors\n-----------------\n\nTo ensure reliable and consistent behavior between driver implementations, in\nAndroid 11, any non-success error codes returned from\nthe HAL are treated as programming errors, recovery from which requires\nrestarting the HAL process. This is a last-resort recovery strategy and the\nexpectation is that such cases won't occur in a properly working system.\n| **Note:** Although these errors are being called out as valid in the HAL API documentation, there is ambiguity as to when and under what states these error codes are returned and what the expected error recovery procedure is. Hence, Android 11 mandates stricter conformance of Sound Trigger HAL implementations at runtime than the lower versions of Android."]]
